Logical queries in a distributed stream processing system

ABSTRACT

Techniques for implementing logical queries in a distributed stream processing system using automatic branching and joins. An exemplary technique includes determining a query is a logical query. The logical query includes two or more summaries based on different groups configured to execute in a single query stage of a stream analytics application. The technique further includes converting the logical query into one or more physical queries. The one or more physical queries are separated into individual query stages, and each of the query stages includes a summary from the two or more summaries that is based on an associated group. The technique further includes generating a directed acyclic graph for the one or more physical queries. The directed acyclic graph includes a physical query transformation for each of the individual query stages.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application No.62/565,483 filed on Sep. 29, 2017, the entirety of which is incorporatedherein by reference.

FIELD OF THE INVENTION

The present disclosure relates generally to complex event processing,and more particularly, to techniques for implementing logical queries ina distributed stream processing system.

BACKGROUND

In traditional database systems, data is stored in one or more databasesusually in the form of tables. The stored data is then queried andmanipulated using a data management language such as a structured querylanguage (SQL). For example, a SQL query may be defined and executed toidentify relevant data from the data stored in the database. A SQL queryis thus executed on a finite set of data stored in the database.Further, when a SQL query is executed, it is executed once on the finitedata set and produces a finite static result. Databases are thus bestequipped to run queries over finite stored data sets.

A number of modern applications and systems however generate data in theform of continuous data or event streams instead of a finite data set.Examples of such applications include but are not limited to sensor dataapplications, financial tickers, network performance measuring tools(e.g. network monitoring and traffic management applications),clickstream analysis tools, automobile traffic monitoring, and the like.Such applications have given rise to a need for a new breed ofapplications that can process the data streams. For example, atemperature sensor may be configured to send out temperature readings ina continuous manner and hardware components or software applicationsneed to be able to process (e.g., query) the continuous and everchanging stream of data.

Managing and processing data for these types of event stream-basedapplications involves building data management and querying capabilitieswith a strong temporal focus. A different kind of querying mechanism isneeded that comprises long-running queries over continuous unboundedsets of data. While some vendors now offer product suites geared towardsevent streams processing, these product offerings still lack theprocessing flexibility required for handling today's event processingneeds. Accordingly, new techniques are desired for processing continuousdata or event streams.

BRIEF SUMMARY

Techniques are provided (e.g., a method, a system, non-transitorycomputer-readable medium storing code or instructions executable by oneor more processors) for implementing logical queries in a distributedstream processing system.

In various embodiments, a method is provided for that includesdetermining a query is a logical query. The logical query includes twoor more summaries based on different groups configured to execute in asingle query stage of a stream analytics application. The method furtherincludes converting the logical query into one or more physical queries.The one or more physical queries are separated into individual querystages, and each of the query stages includes a summary from the two ormore summaries that is based on an associated group. The method furtherincludes generating a directed acyclic graph for the one or morephysical queries. The directed acyclic graph includes a physical querytransformation for each of the individual query stages.

In some embodiments, the determining the query is the logical queryincludes determining the logical query comprises a first summary of thetwo or more summaries based on a first group of the different groups anda second summary of the two or more summaries based on a second group ofthe different groups, and where the first group is different from thesecond group.

In some embodiments, the converting the logical query to the one or morephysical queries includes parsing the logical query into the firstsummary based on the first group and the second summary based on thesecond group, and translating logical syntax and semantics for the firstsummary based on the first group into physical syntax and semantics fora first physical query comprising the first summary based on the firstgroup and physical syntax and semantics for a second physical querycomprising the second summary based on a second group.

In some embodiments, the first physical query is configured to executein a first query stage and the second physical query is configured toexecute in a second query stage. Optionally, the directed acyclic graphcomprises the first query stage as a first physical querytransformation, the second query stage as a second physical querytransformation, and a join transformation to join output from each ofthe first physical query transformation and the second physical querytransformation into a single output shape.

In some embodiments, the method further comprises: determining whetherparallelism is exhibited in each of the one or more physical queries,when parallelism is not exhibited in a physical query of the one or morephysical queries, determining an input stream is to be partitioned orrepartitioned for the physical query, when the input stream is to bepartitioned or repartitioned for the physical query, creating apartition transformation for the physical query. Optionally, thepartition transformation is incorporated into the directed acyclic graphprior to the physical query transformation for the physical query.

In some embodiments, the creating the partition transformation includesdetermining a partitioning criteria for the physical query, where thepartitioning criteria is an attribute within physical syntax of thephysical query that is acted upon or part of a function ortransformation that causes the physical query to not exhibitedparallelism.

In various embodiments, a system is provided for that comprises a dataprocessing system that includes one or more processors andnon-transitory machine readable storage medium having instructionsstored thereon that when executed by the one or more processors causethe one or more processors to perform a process comprising determining aquery is a logical query. The logical query includes two or moresummaries based on different groups configured to execute in a singlequery stage of a stream analytics application. The process furtherincludes converting the logical query into one or more physical queries.The one or more physical queries are separated into individual querystages, and each of the query stages includes a summary from the two ormore summaries that is based on an associated group. The process furtherincludes generating a directed acyclic graph for the one or morephysical queries. The directed acyclic graph includes a physical querytransformation for each of the individual query stages.

In some embodiments, the process further comprises: reading, at theprimary server of a data processing system, the input events from aninput source; reading, at the one or more secondary servers of the dataprocessing system, the input events from the input source; pausing, bythe new primary server of the data processing system, the processing theinput events and the writing of the secondary output events for at leastthe new primary server upon the election of the new primary server; andunpausing, by the new primary server of the data processing system, theprocessing the input events and the writing of the secondary outputevents for at least the new primary server upon the writing the failedprimary output events to the primary target.

In some embodiments, the determining the query is the logical queryincludes determining the logical query comprises a first summary of thetwo or more summaries based on a first group of the different groups anda second summary of the two or more summaries based on a second group ofthe different groups, and where the first group is different from thesecond group.

In some embodiments, the converting the logical query to the one or morephysical queries includes parsing the logical query into the firstsummary based on the first group and the second summary based on thesecond group, and translating logical syntax and semantics for the firstsummary based on the first group into physical syntax and semantics fora first physical query comprising the first summary based on the firstgroup and physical syntax and semantics for a second physical querycomprising the second summary based on a second group.

In some embodiments, the first physical query is configured to executein a first query stage and the second physical query is configured toexecute in a second query stage. Optionally, the directed acyclic graphcomprises the first query stage as a first physical querytransformation, the second query stage as a second physical querytransformation, and a join transformation to join output from each ofthe first physical query transformation and the second physical querytransformation into a single output shape.

In some embodiments, the process further comprises: determining whetherparallelism is exhibited in each of the one or more physical queries,when parallelism is not exhibited in a physical query of the one or morephysical queries, determining an input stream is to be partitioned orrepartitioned for the physical query, when the input stream is to bepartitioned or repartitioned for the physical query, creating apartition transformation for the physical query. Optionally, thepartition transformation is incorporated into the directed acyclic graphprior to the physical query transformation for the physical query.

In some embodiments, the creating the partition transformation includesdetermining a partitioning criteria for the physical query, where thepartitioning criteria is an attribute within physical syntax of thephysical query that is acted upon or part of a function ortransformation that causes the physical query to not exhibitedparallelism.

In various embodiments, a non-transitory machine readable storage mediumis provided for that has instructions stored thereon that when executedby one or more processors cause the one or more processors to perform amethod comprising determining a query is a logical query. The logicalquery includes two or more summaries based on different groupsconfigured to execute in a single query stage of a stream analyticsapplication. The process further includes converting the logical queryinto one or more physical queries. The one or more physical queries areseparated into individual query stages, and each of the query stagesincludes a summary from the two or more summaries that is based on anassociated group. The process further includes generating a directedacyclic graph for the one or more physical queries. The directed acyclicgraph includes a physical query transformation for each of theindividual query stages.

In some embodiments, the process further comprises: reading, at theprimary server of a data processing system, the input events from aninput source; reading, at the one or more secondary servers of the dataprocessing system, the input events from the input source; pausing, bythe new primary server of the data processing system, the processing theinput events and the writing of the secondary output events for at leastthe new primary server upon the election of the new primary server; andunpausing, by the new primary server of the data processing system, theprocessing the input events and the writing of the secondary outputevents for at least the new primary server upon the writing the failedprimary output events to the primary target.

In some embodiments, the determining the query is the logical queryincludes determining the logical query comprises a first summary of thetwo or more summaries based on a first group of the different groups anda second summary of the two or more summaries based on a second group ofthe different groups, and where the first group is different from thesecond group.

In some embodiments, the converting the logical query to the one or morephysical queries includes parsing the logical query into the firstsummary based on the first group and the second summary based on thesecond group, and translating logical syntax and semantics for the firstsummary based on the first group into physical syntax and semantics fora first physical query comprising the first summary based on the firstgroup and physical syntax and semantics for a second physical querycomprising the second summary based on a second group.

In some embodiments, the first physical query is configured to executein a first query stage and the second physical query is configured toexecute in a second query stage. Optionally, the directed acyclic graphcomprises the first query stage as a first physical querytransformation, the second query stage as a second physical querytransformation, and a join transformation to join output from each ofthe first physical query transformation and the second physical querytransformation into a single output shape.

In some embodiments, the method further comprises: determining whetherparallelism is exhibited in each of the one or more physical queries,when parallelism is not exhibited in a physical query of the one or morephysical queries, determining an input stream is to be partitioned orrepartitioned for the physical query, when the input stream is to bepartitioned or repartitioned for the physical query, creating apartition transformation for the physical query. Optionally, thepartition transformation is incorporated into the directed acyclic graphprior to the physical query transformation for the physical query.

In some embodiments, the creating the partition transformation includesdetermining a partitioning criteria for the physical query, where thepartitioning criteria is an attribute within physical syntax of thephysical query that is acted upon or part of a function ortransformation that causes the physical query to not exhibitedparallelism.

The techniques described above and below may be implemented in a numberof ways and in a number of contexts. Several example implementations andcontexts are provided with reference to the following figures, asdescribed below in more detail. However, the following implementationsand contexts are but a few of many.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a stream analytics system in whichtechniques for receiving and processing data streaming from an eventsource may be implemented in accordance with various embodiments.

FIGS. 2A-2D are illustrations of directed acyclic graphs (DAGs) inaccordance with various embodiments.

FIG. 3 is an illustration of a simplified high level diagram of adistributed processing system in accordance with various embodiments.

FIG. 4 depicts a flowchart illustrating a process for implementing alogical query in accordance with various embodiments.

FIG. 5 depicts a simplified diagram of a distributed system forimplementing various embodiments.

FIG. 6 is a simplified block diagram of one or more components of asystem environment by which services provided by one or more componentsof an embodiment system may be offered as cloud services, in accordancewith various embodiments.

FIG. 7 illustrates an example computer system that may be used toimplement various embodiments.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Overview of Complex Event Processing (CEP)

Complex Event Processing (CEP) provides a modular platform for buildingapplications based on an event-driven architecture. At the heart of theCEP platform is the Continuous Query Language (CQL), which allowsapplications to filter, query, and perform pattern matching operationson streams of data using a declarative, SQL-like language. Developersmay use CQL in conjunction with a lightweight Java programming model towrite applications. Other platform modules include a feature-rich IDE,management console, clustering, distributed caching, event repository,and monitoring, to name a few.

As event-driven architecture and complex event processing have becomeprominent features of the enterprise computing landscape, more and moreenterprises have begun to build mission-critical applications using CEPtechnology. Today, mission-critical CEP applications can be found inmany different industries. For example, CEP technology is being used inthe power industry to make utilities more efficient by allowing them toreact instantaneously to changes in demand for electricity. CEPtechnology is being used in the credit card industry to detectpotentially fraudulent transactions as they occur in real time. The listof mission-critical CEP applications continues to grow. The use of CEPtechnology to build mission-critical applications has led to a need forCEP applications to be made highly available and fault-tolerant.

Today's Information Technology (IT) environments generate continuousstreams of data for everything from monitoring financial markets andnetwork performance, to business process execution and tracking RFIDtagged assets. CEP provides a rich, declarative environment fordeveloping event processing applications to improve the effectiveness ofbusiness operations. CEP can process multiple event streams to detectpatterns and trends in real time and provide enterprises the necessaryvisibility to capitalize on emerging opportunities or mitigatedeveloping risks.

A continuous stream of data (also referred to as an event stream) mayinclude a stream of data or events that may be continuous or unboundedin nature with no explicit end. Logically, an event or data stream maybe a sequence of data elements (also referred to as events), each dataelement having an associated timestamp. A continuous event stream may belogically represented as a bag or set of elements (s, T), where “s”represents the data portion, and “T” is in the time domain. The “s”portion is generally referred to as a tuple or event. An event streammay thus be a sequence of time-stamped tuples or events.

In some aspects, the timestamps associated with events in a stream mayequate to a clock time. In other examples, however, the time associatedwith events in an event stream may be defined by the application domainand may not correspond to clock time but may, for example, berepresented by sequence numbers instead. Accordingly, the timeinformation associated with an event in an event stream may berepresented by a number, a timestamp, or any other information thatrepresents a notion of time. For a system receiving an input eventstream, the events arrive at the system in the order of increasingtimestamps. There could be more than one event with the same timestamp.

In some examples, an event in an event stream may represent anoccurrence of some worldly event (e.g., when a temperature sensorchanged value to a new value, when the price of a stock symbol changed)and the time information associated with the event may indicate when theworldly event represented by the data stream event occurred.

For events received via an event stream, the time information associatedwith an event may be used to ensure that the events in the event streamarrive in the order of increasing timestamp values. This may enableevents received in the event stream to be ordered based upon theirassociated time information. In order to enable this ordering,timestamps may be associated with events in an event stream in anon-decreasing manner such that a later-generated event has a latertimestamp than an earlier-generated event. As another example, ifsequence numbers are being used as time information, then the sequencenumber associated with a later-generated event may be greater than thesequence number associated with an earlier-generated event. In someexamples, multiple events may be associated with the same timestamp orsequence number, for example, when the worldly events represented by thedata stream events occur at the same time. Events belonging to the sameevent stream may generally be processed in the order imposed on theevents by the associated time information, with earlier events beingprocessed prior to later events.

The time information (e.g., timestamps) associated with an event in anevent stream may be set by the source of the stream or alternatively maybe set by the system receiving the stream. For example, in certainembodiments, a heartbeat may be maintained on a system receiving anevent stream, and the time associated with an event may be based upon atime of arrival of the event at the system as measured by the heartbeat.It is possible for two events in an event stream to have the same timeinformation. It is to be noted that while timestamp ordering requirementis specific to one event stream, events of different streams could bearbitrarily interleaved.

An event stream has an associated schema “S,” the schema comprising timeinformation and a set of one or more named attributes. All events thatbelong to a particular event stream conform to the schema associatedwith that particular event stream. Accordingly, for an event stream (s,T), the event stream may have a schema ‘S’ as (<time_stamp>,<attribute(s)>), where <attributes> represents the data portion of theschema and can comprise one or more attributes. For example, the schemafor a stock ticker event stream may comprise attributes <stock symbol>and <stock price>. Each event received via such a stream will have atime stamp and the two attributes. For example, the stock ticker eventstream may receive the following events and associated timestamps:

... (<timestamp_N>, <NVDA,4>) (<timestamp_N+1>, <ORCL,62>)(<timestamp_N+2>, <PCAR,38>) (<timestamp_N+3>, <SPOT,53>)(<timestamp_N+4>, <PDCO,44>) (<timestamp_N+5>, <PTEN,50>) ...

In the above stream, for stream element (<timestamp_N+1>, <ORCL,62>),the event is <ORCL,62> with attributes “stock_symbol” and “stock_value.”The timestamp associated with the stream element is “timestamp_N+1”. Acontinuous event stream is thus a flow of events, each event having thesame series of attributes.

As noted, a stream may be the principle source of data that CQL queriesmay act on. A stream S may be a bag (also referred to as a “multi-set”)of elements (s, T), where “s” is in the schema of S and “T” is in thetime domain. Additionally, stream elements may be tuple-timestamp pairs,which can be represented as a sequence of timestamped tuple insertions.In other words, a stream may be a sequence of timestamped tuples. Insome cases, there may be more than one tuple with the same timestamp.And, the tuples of an input stream may be requested to arrive at thesystem in order of increasing timestamps. Alternatively, a relation(also referred to as a “time varying relation,” and not to be confusedwith “relational data,” which may include data from a relationaldatabase) may be a mapping from the time domain to an unbounded bag oftuples of the schema R. In some examples, a relation may be anunordered, time-varying bag of tuples (i.e., an instantaneous relation).In some cases, at each instance of time, a relation may be a boundedset. It can also be represented as a sequence of timestamped tuples thatmay include insertions, deletes, and/or updates to capture the changingstate of the relation. Similar to streams, a relation may have a fixedschema to which each tuple of the relation may conform. Further, as usedherein, a continuous query may generally be capable of processing dataof (i.e., queried against) a stream and/or a relation. Additionally, therelation may reference data of the stream.

In some aspects, the CQL engine may include a full blown query language.As such, a user may specify computations in terms of a query.Additionally, the CQL engine may be designed for optimizing memory,utilizing query language features, operator sharing, rich patternmatching, rich language constructs, etc. Additionally, in some examples,the CQL engine may process both historical data and streaming data. Forexample, a user can set a query to send an alert when California saleshit above a certain target. Thus, in some examples, the alert may bebased at least in part on historical sales data as well as incoming live(i.e., real-time) sales data.

In some examples, the CQL engine or other features of the belowdescribed concepts may be configured to combine a historical context(i.e., warehouse data) with incoming data in a real-time fashion. Thus,in some cases, the present disclosure may describe the boundary ofdatabase stored information and in-flight information. Both the databasestored information and the inflight information may include businessintelligence (BI) data. As such, the database may, in some examples, bea BI server or it may be any type of database. Further, in someexamples, the features of the present disclosure may enable theimplementation of the above features without users knowing how toprogram or otherwise write code. In other words, the features may beprovided in a feature-rich user interface (UI) or other manner thatallows non-developers to implement the combination of historical datawith real-time data.

In some examples, the above concepts may be utilized to leverage therich real-time and continuous event processing capabilities associatedwith complex event processing. Several features may be supported suchas, but not limited to, archived relations. As such, in order toleverage such features (e.g., rich, real-time and continuous eventprocessing), the system may be configured to transparently deal withstartup state and runtime state of relational data. In other words, thesystem may be configured to manage a query that is non-empty at theinstant of its creation (i.e., an archived relation).

In some examples, an archived relation may be utilized. As such, when aCQL engine sees a query that indicates that it is based on an archivedrelation, that archived relation may also indicate that there arecertain entities it can call to query for historical context, forexample. In some examples, a data definition language (DDL) may indicateannotations about the archived relation such as, but not limited to, howto perform the query, what are the important columns in the table,and/or where to send the rest of the data. In some examples, once thequery is constructed in the CQL engine (e.g., as a graph), the systemmay analyze the query graph. Additionally, in some aspects, there arecertain operators that are stateful, like “distinct,” “group aggr,”“pattern,” and/or “group by.” However, stateless operators may just takeinput and send it to the parent, for example, down-stream operators.Thus, one approach is to store the entire table. However, utilizingarchived relations, the system may analyze the query graph and decidewhich of the lowest stateful operators that it can use to query thearchive. In some examples, the system (or one or morecomputer-implemented methods) may retrieve the state at the loweststateful operator reached while traversing the graph. For example, thequery graph may be analyzed in a topological order from the source.Based at least in part on this first stateful operator, the CQL enginemay then determine the optimal amount of data to be fetched in order toinitialize the state of the operators for a query defined over anarchived relation.

In at least one non-limiting example, source operators like relationand/or source may come first in the topological traversal with queryoutput and/or root coming last. For example, if the CQL query lookslike: select sum(c1) from R1 where c2>c25, the plan for this query maylook like: RelationSource→SELECT→GroupAggr. Thus, following thetopological order, and since RelationSource and SELECT are bothstateless, the lowest stateful operator may be GroupAggr. In this way,the stateful operators of a query (GroupAggr in this example) may enablethe query engine to populate the query engine with historical data froma data store prior to receiving streaming data. This may be enabledbased at least in part on the fact that the query is analyzing anarchived relation and the archived relation has been indicated as such.

In some examples, a window size for a given archived relation may bespecified by a user. A window, in some aspects, in relation to anarchived relation, may include a node in a query graph that analyzes orotherwise evaluates incoming streamed content. In other words, thewindow may define the amount of streamed content to be analyzed and/orprocessed by the query engine and/or the amount of historical data thatwill be included in the archived relation.

At a high level, once a window is applied on a Stream it becomes aRelation and then regular relational logic may be applied, as withrelational databases. As tuples arrive and leave the window, theRelation under consideration changes with queries compiled against itemitting results at the same time. CQL may support RANGE (up tonanoseconds granularity), ROWS, PARTITION BY and extensible windows.These windows are examples of stream-to-relation operators. On the otherhand, ISTREAM (i.e., insert stream), DSTREAM (i.e., delete stream) andRSTREAM (i.e., relation stream) are relation-to-stream operators. Insome examples, a user, developer, and/or manager may set the window size(e.g., via a UI) provided by the query engine or one or more computingsystems operating or hosting the query engine. In some examples, awindow on a stream may be a time-based range window. For example, aconfigurable value window on an archived relation may be specified usingwindow size and the attribute on which the window is calculated. Whenthere is a configurable value window specified on top of archivedrelation, a snapshot query may be computed and the snapshot tuples,which are within window limits, may be output. Additionally, after stateinitialization, the value window may be applied on incoming active data.In some examples, only the incoming active data will be inserted intowindow whose window attribute's value is differing from current eventtime for less than the window size.

Additionally, in some examples, features of the present disclosure mayalso leverage the continuous query processing capabilities of the CQLengine and/or CEP engine to support real-time data analysis. In someaspects, the CQL engine and/or CEP engine may have traditionally been astream-oriented analysis engine; however, it may be enhanced to supportstream-oriented data that is backed by a durable store (e.g., thearchived relation described above). For example, the present disclosuredescribes features that may support the notion of a data object (DO)which is a durable store (database and/or table). Modifications made toa DO may cause change notifications to be broadcast to interestedlisteners creating, in effect, a data stream. This data stream may beconsumed by the CQL engine and/or CEP engine in support of any runningqueries; however, the CQL engine and/or CEP engine may not have beendesigned to take into account the existing data in the DO backing store.For example, the CQL engine and/or CEP engine may request that theinitial state of the query running in the CQL engine and/or CEP enginereflect the current state of the DO including all the data currently inthe DO backing store. Once this query is so initialized, the CQL engineand/or CEP engine only need to concern itself with the stream of DOchange notifications from that point on in traditional stream-orientedstyle.

In some aspects, the CQL engine and/or CEP engine may traditionallyprocess streams or non-archived relations, so there may be no initialstate. For example, a query may be loaded, where it may start runningand listening for changes, etc. In some cases, if a user asks for salesby state, in a bar chart, and then somebody makes a new sale, the tablemay get updated and the user may expect to see a change in the graph,pushed out to them. However, if they close the dashboard and come back aweek later and bring up some sales, the user may expect to have the sumof sales according to the table of summed sales data. In other words,the query may need to bring the query up to the state of the archive andthen listen for active changes.

In some aspects, for example, the CQL engine may be pre-initialized withthe archived data. Once initialized, the CQL engine may listen to a JavaMessaging Service (JMS) or other messenger for change notifications(e.g., based at least in part on API calls for inserting, deleting,etc., data from the archive). Thus, services can listen and if the JMSpublishes on the same topic that the listening service is listening on,it may receive the data. The services don't have to know who ispublishing or whether they are, or not. The listening service can justlisten, and if something happens, the listening service may hear it. Insome examples, this is how persistence is decoupled, for instance, fromits consumers. Additionally, in some examples, an alert engine may raisealerts based on what the alert engine hears, potentially, and further, aSQL engine, that may be listening in on process queries of relevance tothe listener.

In some examples, a query may be started in CQL, SQL, and/or CEP engineand instructions may be configured to get the archive data (e.g., toprime the pump) and then start listening to these JMS messages. However,with numerous inserts, deletes, etc., this could include a large amountof information. Additionally, there could be a lag time before themessage is heard by the listener and the listening may, in someexamples, jump in, query the archive, come back, and start listening.Thus, there is a potential for missing and/or double counting an event.

Additionally, if the engine merely runs the query, while it's runningthe query things can go into JMS and be published where the enginewasn't listening. So, the engine may be configured to setup the listenerfirst, run the archive query, and then come back and actually startpulling out of the queue, so that it doesn't miss anything. Thus, theJMS may queue things up and, if things back up it's okay while theengine is doing a query because it can catch up later and it doesn'thave to worry about whether it's synchronous. If it's not here,listening, it won't miss it, it gets queued until the engine comes back,as long as it has its listener established.

Additionally, in some examples, a system column may be added to a user'sdata. This system column may be for indicating transaction IDs toattempt to handle the double counting and/or missing operation problem.However, in other examples, the system may provide or otherwise generatea transaction context table. Additionally, there may be two additionalcolumns TRANSACTION_CID and TRANSACTION_TID. The context table mayalways be maintained by persistence service so as to know thread(context)wise of the last committed transaction ID. The transaction IDsmay be guaranteed to be committed in ascending order for a thread(context). For example, when a server comes up, it may run thepersistence service. Each one may allocate a set of context IDs andtransaction IDs for determining whether data of the pre-initializedinformation includes all of the data that has passed through the JMS.Additionally, in some cases, multiple output servers may be utilized (incompliance with JTA and/or to implement high availability (HA), whereeach server may manage a single set of context/transaction tables thatare completely separate from the other tables managed by the otherservers.

In some embodiments, when a continuous (for example, a CQL) query iscreated or registered, it may undergo parsing and semantic analysis atthe end of which a logical query plan is created. When the CQL query isstarted, for example, by issuing an “alter query <queryname> start” DDL,the logical query plan may be converted to a physical query plan. In oneexample, the physical query plan may be represented as a directedacyclic graph (DAG) of physical operators. Then, the physical operatorsmay be converted into execution operators to arrive at the final queryplan for that CQL query. The incoming events to the CQL engine reach thesource operator(s) and eventually move downstream with operators in theway performing their processing on those events and producingappropriate output events.

Event Processing Applications

The quantity and speed of both raw infrastructure and business events isexponentially growing in IT environments. Whether it is streaming stockdata for financial services, streaming satellite data for the militaryor real-time vehicle-location data for transportation and logisticsbusinesses, companies in multiple industries must handle large volumesof complex data in real-time. In addition, the explosion of mobiledevices and the ubiquity of high-speed connectivity adds to theexplosion of mobile data. At the same time, demand for business processagility and execution has also grown. These two trends have put pressureon organizations to increase their capability to support event-drivenarchitecture patterns of implementation. Real-time event processingrequires both the infrastructure and the application developmentenvironment to execute on event processing requirements. Theserequirements often include the need to scale from everyday use cases toextremely high velocities of data and event throughput, potentially withlatencies measured in microseconds rather than seconds of response time.In addition, event processing applications must often detect complexpatterns in the flow of these events.

The Stream Analytics platform (e.g., the Oracle Stream Analytics (OSA))targets a wealth of industries and functional areas. The following aresome use cases:

Telecommunications: Ability to perform real-time call detail (CDR)record monitoring and distributed denial of service attack detection.

Financial Services: Ability to capitalize on arbitrage opportunitiesthat exist in millisecond or microsecond windows. Ability to performreal-time risk analysis, monitoring and reporting of financialsecurities trading and calculate foreign exchange prices.

Transportation: Ability to create passenger alerts and detect baggagelocation in case of flight discrepancies due to local ordestination-city weather, ground crew operations, airport security, etc.

Public Sector/Military: Ability to detect dispersed geographical enemyinformation, abstract it, and decipher high probability of enemy attack.Ability to alert the most appropriate resources to respond to anemergency.

Insurance: Ability to learn and to detect potentially fraudulent claims.

IT Systems: Ability to detect failed applications or servers inreal-time and trigger corrective measures.

Supply Chain and Logistics: Ability to track shipments in real-time anddetect and report on potential delays in arrival.

Real Time Streaming & Event Processing Analytics

With exploding data from increased number of connected devices, there isan increase in large volumes of dynamically changing data; not only thedata moving within organizations, but also outside the firewall.High-velocity data brings high value, especially to volatile businessprocesses. However, some of this data loses its operational value in ashort time frame. Big Data allows the luxury of time in processing foractionable insight. Fast Data, on the other hand, requires extractingthe maximum value from highly dynamic and strategic data. It requiresprocessing much faster and facilitates taking timely action as close tothe generated data as possible. The stream analytics platform deliverson Fast Data with responsiveness. Oracle Edge Analytics pushesprocessing to the network edge, correlating, filtering and analyzingdata for actionable insight in real-time.

The stream analytics platform provides ability to join the incomingstreaming events with persisted data, thereby delivering contextuallyaware filtering, correlation, aggregation and pattern matching. Itdelivers lightweight, out of the box adapters for common event sources.It also provides an easy-to-use adapter framework for custom adapterdevelopment. With this platform, organizations can identify andanticipate opportunities, and threats represented by seemingly unrelatedevents. Its incremental processing paradigm can process events using aminimum amount of resources providing extreme low latency processing. Italso allows it to create extremely timely alerts, and detect missing ordelayed events immediately, such as the following:

Correlated events: If event A happens, event B almost always followswithin 2 seconds of it.

Missing or Out-of-Sequence events: Events A, B, C should occur in order.C is seen immediately after A, without B.

Causal events: Weight of manufactured items is slowly trending lower orthe reading falls outside acceptable norms. This signals a potentialproblem or future maintenance need.

In addition to real-time event sourcing, the stream analytics platformdesign environment and runtime execution supports standards-based,continuous query execution across both event streams and persisted datastores like databases and high performance data grids. This enables theplatform to act as the heart of intelligence for systems needing answersin microseconds or minutes to discern patterns and trends that wouldotherwise go unnoticed. Event Processing use cases require the speed ofin-memory processing with the mathematical accuracy and reliability ofstandard database SQL. This platform queries listen to incoming eventstreams and execute registered queries continuously, in-memory on eachevent, utilizing advanced, automated algorithms for query optimization.While based on an in-memory execution model, however, this platformleverages standard ANSI SQL syntax for query development, thus ensuringaccuracy and extensibility of query construction. This platform is fullycompliant with the ANSI SQL '99 standard and was one of the firstproducts available in the industry to support ANSI SQL reviewedextensions to standard SQL for real-time, continuous query patternmatching. The CQL engine optimizes the execution of queries within aprocessor leaving the developer to focus more on business logic ratherthan optimization.

The stream analytics platform allows for both SQL and Java code to becombined to deliver robust event processing applications. Leveragingstandard industry terminology to describe event sources, processors, andevent output or sinks, this platform provides a meta-data drivenapproach to defining and manipulating events within an application. Itsdevelopers use a visual, directed-graph canvas and palette forapplication design to quickly outline the flow of events and processingacross both event and data sources. Developing the flow through drag anddrop modeling and configuration wizards, the developer can then enterthe appropriate metadata definitions to connect design toimplementation. When necessary or preferred, with one click, developersare then able to drop into custom Java code development or use theSpring® framework directly to code advanced concepts into theirapplication.

Event driven applications are frequently characterized by the need toprovide low and deterministic latencies while handling extremely highrates of streaming input data. The underpinning of the stream analyticsplatform is a lightweight Java container based on an OSGi® backplane. Itcontains mature components from the WebLogic JEE application server,such as security, logging and work management algorithms, but leveragesthose services in a real-time event-processing environment. Anintegrated real-time kernel provides unique services to optimize threadand memory management supported by a JMX framework enabling theinteraction with the container for performance and configuration. Web2.0 rich internet applications can communicate with the platform usingthe HTTP publish and subscribe services, which enables them to subscribeto an application channel and have the events pushed to the client. Witha small footprint this platform is a lightweight, Java-based container,that delivers faster time-to-production and lower total cost ofownership.

The stream analytics platform has the ability to handle millions ofevents per second with microseconds of processing latencies on standard,commodity hardware or optimally with Oracle Exalogic and its portfolioof other Engineered Systems. This is achieved through a complete“top-down” layered solution, not only with a design focus on highperformance event processing use cases, but also a tight integrationwith enterprise-class real-time processing infrastructure components.The platform architecture of performance-oriented server clustersfocuses on reliability, fault tolerance and extreme flexibility withtight integration into the Oracle Coherence technology and enables theenterprise to predictably scale mission-critical applications across adata grid, ensuring continuous data availability and transactionalintegrity.

In addition, this platform allows for deterministic processing, meaningthe same events can be fed into multiple servers or the same server atdifferent rates achieving the same results each time. This enablesincredible advantages over systems that only rely on the system clock ofthe running server.

Stream Analytics Architecture

Embodiments of the present disclosure provide techniques for receivingand processing data form a source. There are two kinds of sources instream analytics: streams and references. Though sources serve as aninput to a pipeline, the two types of source are different. A stream isa representation of streaming event data while a reference is that ofstatic data. Streaming event data is flowing into the system and is tobe processed, whereas static data is used to enrich streaming event databy pulling the static data from a static data source. The initial orprimary source of a pipeline is typically a stream of event data.However, additional sources can be both streams and/or references.

In various embodiments, stream analytics is an event processing serverdesigned to support event processing applications in embeddedenvironments such as those supported by the Java Embedded Suite (JES).The stream analytics system comprises a stream analytics server, streamanalytics Visualizer, a command-line administrative interface, and anIntegrated Development Environment (IDE). The stream analytics serverhosts logically related resources and services for running streamanalytics applications. Servers may be grouped into and managed asdomains. A domain can have one server (standalone-server domain) or many(multiserver domain). The stream analytics' domains and servers may bemanaged through the stream analytics visualizer and the command-lineadministrative interface. In some embodiments, the stream analyticsvisualizer is a web-based user interface through which stream analyticsapplications running on the stream analytics server are deployed,configured, tested, and monitored. In some embodiments, the command-lineadministrative interface enables a user to manage the server from thecommand line and through configuration files. For example, the user maystart and stop domains and deploy, suspend, resume, and uninstall anapplications. Advantageously, the stream analytics system is developedto simplify the complex event processing operations and make themavailable even to users without any technical background.

A stream analytics application receives and processes data streamingfrom an event source. A stream is a source of dynamic data. The data isflowing, it is not static or frozen. For example, stock prices of aparticular company can be considered as a stream as the data arrives inevery second or even more frequently. Another example of streaming datais the position (geographical location) of vehicles (e.g., trucks) whichagain can change continuously as each vehicle is moving. Each vehiclereports its own position to a central system periodically, e.g. everysecond, and the central system receives the position messages as astream. Streams may be transmitted using different network protocols,messaging systems as well as using many different message formats. Forexample, the stream types may include Kafka and GoldenGate. To create aKafka stream, a user may create a Kafka connection first, and thenselect that connection in a stream creation wizard. In addition to theconnection, the user may specify the Kafka topic that represents thestream of data. When the stream is created, the shape or format of thedata is specified. In stream analytics, each message (or event, instream processing terminology) in a stream or target should have thesame format and this format may be specified when creating the stream ortarget. The shape or format of the event is analogous to the databasetable structure for static data. Each shape consists of a number offields and each field has a name and a data type. In the stream creationwizard, it may be possible to assign an alias to a field, so that thefield can later be referenced by the user-given alias.

While monitoring the data, the stream analytics application mightidentify and respond to patterns, look for events that meet specifiedcriteria and alert other applications, or do other work that requiresimmediate action based on quickly changing data. The stream analyticssystem uses an event-driven architecture where an application is brokeninto a set of stages (nodes) connected by queues. Each application mayinclude one or more pipelines that define the pipeline logic and is asequence of data processing stages connected by the queues. A pipelinetypically starts with a stream and can optionally end with a target. Atarget represents an external system where the results of the streamprocessing are being directed. Just like streams, targets are the linksto the outside world. Streams are the input to a pipeline, whereastargets are the output. In various embodiments, a pipeline may consumeand process multiple streams, with a single target. In some embodiments,the output stream of one stage is used as an input to another stage anda pipeline can be of arbitrary length with any combination of abovestage types. A user can edit/update configuration on any stage, notlimited to last stage (the stage before the target) in a draft pipeline.

In stream analytics, the channel component represents the queues whileall of the other components represent stages. Every component in thedata processing system, e.g., an event processing network (EPN), has arole in processing the data. The data processing system is the primarypoint where application components are wired together. In variousembodiments, using a CEP integrated development environment (IDE), auser can use an EPN Editor and visualizer that provides a graphical viewof the EPN and offers visualization and navigation features to help theuser build CEP applications. In some embodiments, the EPN is linear withdata entering the EPN through an adapter where it is converted to anevent. After the conversion, events pass through the stages from one endto the other. At various stages in the EPN, the component can executelogic or create connections with external components as needed. UsingOracle CEP IDE for Eclipse, you can use an EPN Editor that provides agraphical view of the EPN and offers visualization and navigationfeatures to help a user build applications.

In various embodiments, the EPN editor is used to configure the variousstages of a pipeline with an application. A stage may be one of thefollowing types: Query, Pattern, Rule, Query Group. A query stage isused to configure a SQL-like query on the data stream and comprisesadditional sources for joins, filters, summaries, group by, timewindows, and so on. For example, the following query may be configuredusing the EPN editor to calculate hourly total sales where transactionamount is greater than a dollar and outputs the result every 1 second.

Select sum (TransactionAmount) As HourlySales From SalesStream [Range 1Hour Slide 1 Second] Where TransactionAmount > 1Queries like the above or more complex queries may be configured in thequery stage with zero to little coding and with no intimate knowledge ofCQL. The CQL language is similar to SQL but with additional constructsfor temporal analytics and pattern matching.

A query stage may include the following subsections: (1) filter, (ii)correlation, (iii) summary/group by, (iv) range, and (v) evaluationfrequency. The filter section in a query stage or query group stageallows events in the data stream to be filtered out. For example, onlyevents which satisfy the filter condition are passed to the downstreamstage. For example, in a data stream containing SensorId andTemperature, you can filter events where Temperature is lower than orequal to 70 degrees by setting the filter condition to Temperature>70.The correlation section in a query stage or query group stage is used toenrich the incoming event in the data stream with static data from areference such as a database table or with data from other streams. Forexample, if the event in the data stream only includes SensorId andSensor Temperature, the event could be enriched with data from a tableto obtain SensorMake, SensorLocation, SensorThreshold, and many more.Correlating an event with other sources may be accomplished with a joincondition based on a common key. In the above example, the SensorId fromthe stream can be used to correlate with SensorKey in the databasetable.

The summary section in a query stage or query group stage is used tosummarize the data over any time range including an unbounded range.Summaries may be defined using one or more aggregate functionsincluding, for example, MIN, MAX, AVG, SUM, and COUNT. For example, auser can continuously compute the maximum temperature for each sensorfrom the beginning of time by configuring a query like the followingquery.

Select SesnsorId, max(Temperature) From TemperatureStream Group BySensorIdThe group by section in a query stage or query group stage collects thedata of all the rows with an identical column value. Group by is used inconjunction with Summaries (aggregate functions) to provide informationabout each group. Follows is an example configuration that generates aquery for computing the average temperature of each sensor at the end ofthe hour and using readings from last one hour.

Select SesnsorId, avg(Temperature) From TemperatureStream [Range 1 HourSlide 1 Hour] Group By SensorId

The range section in a query stage or query group stage is used tocreate a window applied on the data stream. Since data stream is anunbounded sequence of events it is often necessary to apply a windowwhen computing aggregates. Examples of ranges include—Last 1 Hour ofevents, Last 5 Minutes of events, Last 10 Events, and many more. Theevaluation frequency or window slide section in a query stage or querygroup stage is used to determine how often a user may want to see theresults. In the above query, if result is only desired at the end of thehour then the user may set the Evaluation Frequency to 1 hour.

A rule stage is a stage in the pipeline where a user may applyconditional (IF-THEN) logic to the events in the stream. A user maycheck for specific conditions and assign values to fields based on theresults of your checks. A user may add multiple rules to the stage andthey will get applied to pipeline in the sequence they are added. Apattern stage allows the user to specify a one or more key fields todiscover an interesting result. For example, a user may create patternstages within the pipeline to discover trends within the event data. Aquery group stage allows a user to configure aggregations on multiplegroup bys and multiple windows. It is a collection of groups, where eachof the group has its own window, filters that affect the data processingonly within that group.

FIG. 1 is a graphical representation of a data processing system such asan EPN that may incorporate an embodiment of the present disclosure. Asillustrated in FIG. 1, the EPN 100 may be made up of several stages thateach serve a distinct role in the processing of events in an eventstream. Events are by definition time-based, so a stream is that sensethe natural condition of events. It is how event data arrives at anevent processing application. To process events with event processing,an application is built whose core is an EPN such as EPN 100. The EPN100 is made up of stages that each serve a distinct role in processingevents, from receiving event data to querying the data to executinglogic based on what is discovered about the events. The applicationreceives raw event data, binds the data to event types, then routes theevents from stage to stage for processing. Connected stages in an EPNprovide a way to execute different kinds of code against events passingthrough the EPN. Kinds of stages can include an adapter, a processor,and a bean. More specifically, in various embodiments, the EPN 100includes event sources 105 that receive events, channels 110 thatconnect stages, an event processing service (EPS) 115 (also referred toas CQ Service) that is configured to provide an environment forprocessing event streams, and/or sinks 120 that perform generalprocessing logic.

In some embodiments, event sources 105 include, without limitation, anadapter (e.g., JMS, HTTP, and file), a channel, a processor, a table, acache, and the like. For example the event source 105 may include one ormore adapters. The one or more adapters may interface directly to aninput and output stream and relation sources and sinks. The one or moreadapters may be configured to understand the input and output streamprotocol, and are responsible for converting the event data into anormalized form that can be queried by an application processor. Forexample, an adapter could receive event data and bind it to an eventtype instance, then pass the event along to EPS 115. The one or moreadapters may be defined for a variety of data sources and sinks. Thechannels 110 act as event processing endpoints. Among other things, thechannels 110 are responsible for queuing event data until an eventprocessing agent can act upon the event data. The EPS 115 may compriseevent processing agents configured to perform one or more actions uponthe event data such as the execution of queries on the event data.

The event sources 105 generate event streams that are received by EPS115. EPS 115 may receive one or more event streams from one or moreevent sources 105. For example, as shown in FIG. 1, EPS 115 receives afirst input event stream 125 from event source 105(a), a second inputevent stream 130 from event source 105(b), and a third event stream 135from event source 105(c). One or more event processing applications(140, 145, and 150) may be deployed on and executed by EPS 115. An eventprocessing application executed by EPS 115 may be configured to listento one or more input event streams, process the events received via theone or more event streams based upon processing logic that selects oneor more events from the input event streams as notable events. Thenotable events may then be sent to one or more event sinks 120 in theform of one or more output event streams. For example, in FIG. 1, EPS115 outputs a first output event stream 155 to event sink 120(a), and asecond output event stream 160 to event sink 120(b). Examples of eventsinks include, without limitation, an adapter (e.g., JMS, HTTP, andfile), a channel, a processor, a cache, and the like. In certainembodiments, event sources, event processing applications, and eventsinks are decoupled from each other such that one can add or remove anyof these components without causing changes to the other components.

In some embodiments, EPS 115 may be implemented as a Java servercomprising a lightweight Java application container, such as one basedupon Equinox OSGi, with shared services. In some embodiments, EPS 115may support ultra-high throughput and microsecond latency for processingevents, for example, by using JRockit Real Time. EPS 115 may alsoprovide a development platform (e.g., a complete real time end-to-endJava Event-Driven Architecture (EDA) development platform) includingtools (e.g., CEP Visualizer and CEP IDE) for developing event processingapplications. An event processing application is configured to listen toone or more input event streams, execute logic (e.g., a query) forselecting one or more notable events from the one or more input eventstreams, and output the selected notable events to one or more eventsources via one or more output event streams.

FIG. 1 provides a drilldown for one such event processing application145. As shown in FIG. 1, event processing application 145 is configuredto listen to input event stream 130, execute a continuous query usingCQL processor 165 comprising logic for selecting one or more notableevents from input event stream 130, and output the selected notableevents via output event stream 160 to event sink 120(b). Although eventprocessing application 145 is shown as listening to one input stream andoutputting selected events via one output stream, this is not intendedto be limiting. In alternative embodiments, an event processingapplication may be configured to listen to multiple input streamsreceived from one or more event sources, select events from themonitored streams, and output the selected events via one or more outputevent streams to one or more event sinks. The same query can beassociated with more than one event sink and with different types ofevent sinks.

Due to its unbounded nature, the amount of data that is received via anevent stream is generally very large. Consequently, it is generallyimpractical and undesirable to store or archive all the data forquerying purposes. The processing of event streams requires processingof the events in real time as the events are received by EPS 115 withouthaving to store all the received events data. EPS 115 therefore providesa special querying mechanism that enables processing of events to beperformed as the events are received by EPS 115 without having to storeall the received events. In particular, event-driven applications of EPS115 are typically rule-driven and these rules may be expressed in theform of continuous queries that are used to process input streams. Acontinuous query may comprise instructions (e.g., business logic) thatidentify the processing to be performed for received events includingwhat events are to be selected as notable events and output as resultsof the query processing. Continuous queries may be persisted to a datastore and used for processing input streams of events and generatingoutput streams of events. Continuous queries typically perform filteringand aggregation functions to discover and extract notable events fromthe input event streams. As a result, the number of outbound events inan output event stream is generally much lower than the number of eventsin the input event stream from which the events are selected.

Unlike a SQL query that is run once on a finite data set, a continuousquery that has been registered by an application with EPS 115 for aparticular event stream may be executed each time that an event isreceived (or if a slide is used each window) in that event stream. Aspart of the continuous query execution, EPS 115 evaluates the receivedevent based upon instructions specified by the continuous query todetermine whether one or more events are to be selected as notableevents, and output as a result of the continuous query execution. Thecontinuous query may be programmed using different languages. In certainembodiments, continuous queries may be configured using the CQL providedby Oracle Corporation and used by Oracle's Complex Events Processingproduct offerings. Oracle's CQL is a declarative language that can beused to program queries (referred to as CQL queries) that can beexecuted against event streams. In certain embodiments, CQL is basedupon SQL with added constructs that support processing of streamingevents data.

In various embodiments, an event processing application may be composedof the following component types: (i) one or more adapters 170 thatinterface directly to the input and output stream and relation sourcesand sinks; (ii) one or more channels 110 that act as event processingendpoints; (iii) one or more application processors 175 (or eventprocessing agents) configured to consume normalized event data from achannel, process it using queries to select notable events, and forward(or copy) the selected notable events to an output channel; (iv) one ormore beans 180 configured to listen to the output channel, and aretriggered by the insertion of a new event into the output channel; and(v) one or more event beans 185 registered to listen to the outputchannel, and are triggered by the insertion of a new event into theoutput channel. In certain embodiments, an assembly file may be providedfor an event processing application describing the various components ofthe event processing application, how the components are connectedtogether, event types processed by the application. Separate files maybe provided for specifying the continuous query or business logic forselection of events.

The adapters 170 may configured to understand the input and outputstream protocol, and are responsible for converting the event data intoa normalized form that can be queried by an application processor. Theadapters 170 may forward the normalized event data into channels oroutput streams and relation sinks. Event adapters may be defined for avariety of data sources and sinks. The processors 175 may comprise a CQLprocessor that contains query code in CQL that may be associated withone or more CQL queries that operate on the events offered by an inputchannel (e.g., a channel 110). For example, the processor's CQL code canquery the events (as SQL code queries database rows), looking forparticular patterns in the data as it flows through the EPN 100. The CQLprocessor may be connected to an output channel (e.g., a channel 110) towhich query results are written. For example, events that meet thepattern criteria could be passed along to a bean 180 (e.g., written inJava) or code, where the data could be used in a calculation with dataretrieved from an external source. A further downstream bean 185 or codecould use the calculation result to execute a process using an externalcomponent. The beans 185 or code may be registered to listen to theoutput channel 110, and are triggered by the insertion of a new eventinto the output channel 110. In some embodiments, the processing logicfor the beans 180/185 may be written in a programming language such asJava or a plain-old-Java-object (POJO). In some embodiments, theprocessing logic may use the CEP event bean API so that the beans180/185 can be managed by CEP. Any component designed to receive or sendevents in the EPN 100 (such as EPN stages) may be been implementedspecifically to do so. Components that are able to receive events areknown as the event sinks 120, while components that send events areknown as the event sources 105. A single component could be both anevent source and a sink. The described stage components included inevent processing, such as adapters and the components on which CQLprocessors are based, already support required functionality. Developerscan add event sink and source support to beans, new adapters, and othercode they write by implementing interfaces from the CEP API.

It should be appreciated that system 100 depicted in FIG. 1 may haveother components than those depicted in FIG. 1. Further, the embodimentshown in FIG. 1 is only one example of a system that may incorporate anembodiment of the present disclosure. In some other embodiments, system100 may have more or fewer components than shown in FIG. 1, may combinetwo or more components, or may have a different configuration orarrangement of components. System 100 can be of various types includinga service provider computer, a personal computer, a portable device(e.g., a mobile telephone or device), a workstation, a network computer,a mainframe, a kiosk, a server, or any other data processing system. Insome other embodiments, system 100 may be configured as a distributedsystem where one or more components of system 100 are distributed acrossone or more networks in the cloud.

The one or more of the components depicted in FIG. 1 may be implementedin software, in hardware, or combinations thereof. In some embodiments,the software may be stored in memory (e.g., a non-transitorycomputer-readable medium), on a memory device, or some other physicalmemory and may be executed by one or more processing units (e.g., one ormore processors, one or more processor cores, one or more GPUs, etc.).

Logical Queries in a Distributed Stream Processing System

Computations on data streams can be challenging due to multiple reasons,including the size of a dataset. Certain metrics such as quantiles needto iterate over the entire dataset in a sorted order using standardfunctions/practices, but standard functions/practices may not be themost suited approach, for example, mean=sum of value/count. For astreaming dataset with multiple attributes, this is not fully scalable.Instead, suppose the SUM and COUNT are stored and each new item is addedto the SUM. For every new item, the COUNT is incremented, and wheneveran AVG is needed, the SUM is divided by the COUNT to obtain the AVG atthat instance. These are known as aggregate functions and are powerfulSQL tools that compute numerical calculations on streaming data,allowing a query to return summarized information about a given columnor result set.

A GROUP BY statement is often used with aggregate functions (COUNT, MAX,MIN, SUM, AVG) to group the result-set by one or more columns or rows.The GROUP BY statement applies to all aggregate functions in a summaryclause. Accordingly, if a user wants to use two or more different GROUPBY statements to aggregate the result-set into different buckets, thenthis is not conventionally possible in a single summary or query stageand a user has to use multiple summary or query stages (e.g., subqueries) and include a join function to combine the results of themultiple summary or query stages. Take for example a working busadvertisement demo that: (1) receives an input shape of an event for thedata set that contains the following attributes: a time stamp, ad ID,location displayed, time of day, ad category and revenue per impression;(2) inputs the data set into a continuous query (the query comprisingtwo stages: i) Count All Advertisement by Ad Category; and ii) SumRevenue Impressions of all advertisements For Every Time Of Day (i.e.,Total Ad Revenue from advertisements displayed in morning), which isessentially two aggregate functions based on two different criteria orattributes; and (3) outputs an output shape of an event for the data setthat contains the following attributes: time stamp, total ad count bycategory, ad category, total revenue by time of day, and time of day, asshown in below in the below Example (1).

Example (1)

Input Stream:

Timestamp AD_ID LocationDisplayed TimeOfDay AD_CategoryRevenue_Per_Impression 1 1001 Market St, San Francisco Morning Gifts0.65 2 1002 Mission St, San Francisco Evening Health 0.77 3 1003Financial District, San Morning Stationary 0.89 Francisco 4 1004 Pier39, San Francisco Evening Gifts 0.77Expected Output Stream:

Timestamp Total_AD_Count_By_Category AD_CategoryTotal_Revenue_By_TimeOfDay Time_Of_Day 1 1 Gifts 0.65 Morning 2 1 Health0.77 Evening 3 1 Stationary 1.54 Morning 4 2 Gifts 1.54 Evening

In this instance, since two different GROUP BY statements are includedin the query (i.e., COUNT summary is based on group defined by“Ad_Category” and SUM summary is based on group defined by “TimeOfDay”),a user would need to set up two different query stages in the pipelinewith each query stage processing a query for each GROUP BY. A joinfunction would also need to be included to combine the results of eachquery to obtain the above output shape. However, this is inefficient andusers would like to compute multiple aggregate functions in a singlequery stage without having to worry about creating multiple aggregatefunctions in parallel on multiple query stages and then joining theresults back into a single output shape.

Logical Syntax Query

To address the above problem, various embodiments are directed to atechnique for introducing a new syntax (logical syntax) and semanticsfor aggregate functions and associate them with logical CQL.

For example, a conventional query plan may include two summaries (COUNTand SUM) expressed with physical syntax in two different query stages(tksummarygroupl_v3 and tksummarygroupl_v4) as shown in Example (2).

Example (2)

CREATE VIEW tksummarygroupl_v3 AS ISTREAM  (SELECT COUNT (ad_id) AStotalads_by_ad_category, ad_category AS ad_category FROMtksummarygroupl_S1 [RANGE 5 seconds] GROUP BY ad_category ) CREATE VIEWtksummarygroupl_v4 AS ISTREAM  (SELECT SUM (revenue) ASsumrevenue_by_timeofday, time_of_day AS time_of_day FROMtksummarygroupl_S1 [RANGE 5 seconds] GROUP BY time_of_day ) CREATE querytksummarygroupl_q2 AS ISTREAM  (SELECT R1.totalads_by_ad_category AStotalads_by_ad_category, R1.ad_category AS ad_category,R2.sumrevenue_by_timeofday AS sumrevenue_by_timeofday, R2.time_of_day AStime_of_day FROM tksummarygroupl_v3 [NOW] AS R1 LEFT OUTER JOINtksummarygroupl_v4 [NOW] AS R2 ON R1.ELEMENT_TIME = R2.ELEMENT_TIMEUNION SELECT R1.totalads_by_ad_category AS totalads_by_ad_category,R1.ad_category AS ad_category, R2.sumrevenue_by_timeofday ASsumrevenue_by_timeofday, R2.time_of_day AS time_of_day FROMtksummarygroupl_v3 [NOW] AS R1 RIGHT OUTER JOIN tksummarygroupl_v4 [NOW]AS R2 ON R1.ELEMENT_TIME = R2.ELEMENT_TIME )To compute this query plan with physical CQL a view is expressed foreach query stage and the output of each view is then joined to generatethe final output shape of events.

In various embodiments, a logical syntax is used to convert aconventional query plan with physical CQL queries for multiple summariesexecuted respectively in multiple query stages into a query plan withlogical CQL queries for multiple summaries executed in a single querystage. In other embodiments, a creation application is used to create aquery plan with logical CQL queries for multiple summaries executed in asingle query stage using logical syntax. The logical syntax of aggregatefunctions (or summary) in summary groups may look like the following:

function_identifier ( [DISTINCT] arith_expr [BY group_by_attrs ] [WITHINwindow_spec ] [ WHERE condition ]); Note: Entries in the square bracketsare optional syntax.For example, the logical syntax for the conventional query plan shown inExample (2) would be as follows:

SELECT COUNT(AD_ID BY AD_Category) AS Total_AD_Count_By_Category,SUM(Revenue_Per_Impression BY TimeOfDay) AS Total_Revenue_By_TimeOfDayFROM BUS_STREAM.

In the logical syntax, the window, the filter, and the grouping criteriaare associated with each aggregate function. In other words, everysummary can have its own grouping criteria, filter, and window in thesame query stage. The semantics of the various sub-clauses used in thelogical syntax include:

-   -   i. function_identifier: Name of Summary (Aggregate Function)        such as COUNT or SUM. This should be a valid CQL aggregate        function.    -   ii. arith_expr: Arithmetic expression whose values are being        aggregated such as AD_ID or Revenue_Per_Impression.    -   iii. group_by_attrs: List of Group By Attributes such as BY        AD_Category or BY TimeOfDay.    -   iv. window_spec: Window Specification such as WITHIN. Window can        be RANGE WINDOW, ROW WINDOW, VALUE WINDOW with or without Slide        specification.    -   v. condition: A Simple or Complex Filter Condition such as        WHERE.

By way of further example, the various sub-clauses may also cometogether as follows:

COUNT(AD_ID BY AD_Category WITHIN 5 MINUTES)—This function will countall AD_IDs per AD_Category in a window of the Last 5 minutes.

AVG(Revenue_Per_Impression BY TimeOfDay WHERE LocationDisplayed like “%Market St, San Francisco %”)—This function will count average revenue ofall Advertisements for every time of day based on the display locationfilter of Market St, San Francisco.

This solution is an improvement over prior industry solutions thatutilize GROUP BY statements with aggregate functions. Conventionallythis is not possible in a single summary or query stage (i.e., in theuser interface of typical databases include a GROUP BY selection thatapplies to all summaries within the query stage and a user cannot add adifferent GROUP BY for a particular summary). Instead, a user has torely on multiple query stages, which involves join functions. Forexample, some databases permit two or more different GROUP BY statementsto be used in different sub queries. However, these databases utilizecomplex and compute-intensive join functions with the sub queries toobtain the output shape with the expected output data. The logicalsyntax disclosed in various embodiments herein eliminates the need of acomplex and compute-intensive join stage as used in previous continuousqueries.

Transforming and Processing Complex Logical Continuous Queries Using aDag of Executable Transformations

Typically a query plan is executed in a data processing system across adistributed cluster of nodes where various query stages may be processedon a number of nodes. However, this type of cluster system can be aproblem for a query plan with logical CQL queries where a single querystage may comprise multiple summaries based on different groups. Forexample, a typical stream analytics application having a query plan witha physical CQL query may be represented as a directed acyclic graph(DAG) of physical operators or executable transformations. Every stage(e.g., query or pattern stage) in the DAG receives one or more inputstreams and transforms the one or more input streams into an outputstream as per the stage's implementation. The output steams may then bejoined into an output shape of events. In some stream analyticsapplications, in order to run a physical CQL query in a distributedcluster (e.g., distributed nodes of a cluster), a stage is created inthe application for a CQL based transformation such as a summary. Forexample, in the following stream analytics application:

val inputStream = AppContext.socketTextStream(“localhost”, 9999) valcqlOutput = AppContext.cql(“select count(*) from input”,.....)cqlOutput.print( )two transformations are defined. The first is a socket texttransformation and the second is a CQL transformation. Accordingly, thisapplication could be represented as a DAG 200 of executabletransformations 205, as shown in FIG. 2A.

In the above approach, the CQL transformation is executing a continuousquery (stateful or stateless). In particular, the CQL transformationstage receives a stream of events and processes the events through aquery plan for a continuous query. The query plan for each physical CQLtransformation stage is typically simple and does not include complexrelational operations such as two or more different GROUP BY statementsto aggregate the result-set into different buckets, and/or two or morewindow or condition statements to apply multiple windows and conditionsto the aggregate functions. The problem is that for query plans that aremore complex (e.g., those that use the newly proposed logicalsyntax/semantics to include two or more different GROUP BY statements toaggregate the result-set into different buckets), the DAG created by thecluster for the CQL transformation stage is insufficient to handle thecomplex query plan.

The proposed solution is to determine a DAG of executabletransformations from the logical CQL query, which can be executed on acluster of distributed nodes. Specifically, various embodiments providetechniques that include the following steps: (1) Convert a logical CQLquery to one or more physical CQL queries, and (2) generate a DAG of theone or more physical CQL queries.

As discussed herein, CQL supports two sets of syntax (logical andphysical syntax). Logical syntax is easier to understand and concise forcreating a logical CQL query; however, logical syntax cannot betranslated into an executable query plan represented as a DAG ofphysical operators. Consequently, prior to creating the query plan, thelogical CQL query needs to be transformed using physical syntax into oneor more physical CQL queries. Example (3) illustrates this step forconverting an existing logical CQL syntax based query to multiplephysical CQL syntax based queries.

Example (3)

Logical Query:

SELECT COUNT(AD_ID BY AD_Category) AS Total_AD_Count_By_Category, SUM(Revenue_Per_Impression BY TimeOfDay) AS  Total_Revenue_By_TimeOfDayFROM BUS_STREAM. Converted to the Physical query: CREATE VIEWtksummarygroupl_v3 AS ISTREAM  (SELECT COUNT (ad_id) AStotalads_by_ad_category, ad_category AS ad_category FROMtksummarygroupl_S1 [RANGE 5 seconds] GROUP BY ad_category ) CREATE VIEWtksummarygroupl_v4 AS ISTREAM  (SELECT SUM (revenue) ASsumrevenue_by_timeofday, time_of_day AS time_of_day FROMtksummarygroupl_S1 [RANGE 5 seconds] GROUP BY time_of_day ) CREATE querytksummarygroupl_q2 AS ISTREAM  (SELECT R1.totalads_by_ad_category AStotalads_by_ad_category, R1.ad_category AS ad_category,R2.sumrevenue_by_timeofday AS sumrevenue_by_timeofday, R2.time_of_day AStime_of_day FROM tksummarygroupl_v3 [NOW] AS R1 LEFT OUTER JOINtksummarygroupl_v4 [NOW] AS R2 ON R1.ELEMENT_TIME = R2.ELEMENT_TIMEUNION SELECT R1.totalads_by_ad_category AS totalads_by_ad_category,R1.ad_category AS ad_category, R2.sumrevenue_by_timeofday ASsumrevenue_by_timeofday, R2.time_of_day AS time_of_day FROMtksummarygroupl_v3 [NOW] AS R1 RIGHT OUTER JOIN tksummarygroupl_v4 [NOW]AS R2 ON R1.ELEMENT_TIME = R2.ELEMENT_TIME )

As illustrated in Example (3), a single complex logical continuous queryhaving multiple summaries based on different groups may be convertedinto three physical continuous queries (each with a summary based on asingle group). In various embodiments, a conversion component is addedto the stream analytics application for implementing the conversion ofthe logical query to one or more physical queries. In some embodiments,the conversion component is configured to determine whether a query isexpressed as a logical CQL query or a physical CQL query. In certainembodiments, this determination is made based on the syntax used todefine the query. As used herein, when an action is “triggered by” or“based on” something, this means the action is triggered or based atleast in part on at least a part of the something. In some embodiments,upon determining that the query is expressed as a logical CQL query, theconversion component is further configured to parse the logical CQLquery into multiple portions, for example, one portion for eachfunction, and translate the various portions into separate queries, forexample, a separate query stage for each function, to generate lesscomplex physical CQL queries for the logical CQL query.

Once the logical CQL query is converted to the multiple physical CQLqueries, a DAG of executable transformations may be created comprisingtransformation 205 for each query stage corresponding to a summary(aggregate function) view (e.g., each physical CQL query), as shown inFIG. 2B. Each of these stages will receive the same input stream andcompute the summary individually. The computation of each stage can befurther optimized and will be described in next section. After computingall summaries in parallel, the results may be joined back in anothertransformation stage 215. Along with joining, this additional stage 215may be used to ensure timestamp progression in an instance where thereis no output from either side of the summary inputs.

This solution is an improvement over prior industry solutions thatutilize GROUP BY statements with aggregate functions. Currently this isnot possible in a single CQL transformation stage. Instead, a user hasto rely on multiple CQL transformation stages, which involves joinfunctions. For example, some databases permit two or more differentGROUP BY statements to be used in different sub queries. Each of the subqueries is run as a CQL transformation on its own stage, and thus issimple and a DAG can be created by the cluster for each CQLtransformation on its own stage.

Executing a Dag of Transformations on a Cluster of Distributed Nodes

Once the DAG of executable transformations are created for each querystage, the transformations may be executed and used to compute thetransformations on a cluster of distributed nodes. However, whilecomputing the DAG of executable transformations on the cluster ofdistributed nodes, the input stream may be received in partitions (e.g.,the streaming data may be divided into small micro-batches, for example,for load balancing purposes, that allows for fine-grained allocation ofcomputations to resources) and the processing resources cannot sharestate. For example, if a query plan is executed as a DAG of executabletransformations comprising a COUNT transformation of an attribute suchas busID on multiple nodes of the cluster and a first partition of theinput data is sent to a first node and second partition of input data issent to a second node, then the output of the query plan includesmultiple partial counts (e.g., one count for each partition of data),and there is conventionally no way to share state or join the partialcounts across nodes. Thus, the problem is how to execute the DAG ofexecutable transformations on the cluster of distributed nodes usingpartitioned input data without losing state such that partial counts arenot generated.

The proposed solution is to repartition the data from the input streambased on a parallelism constraint such that each continuous query can becomputed on a same node or set of nodes. Specifically, variousembodiments provide techniques that include the following steps: (1)analyze the query plan and identify each query stage or each physicalCQL query within the query plan; (2) determine whether parallelism isexhibited for each query stage or each physical CQL query; (3) determinewhether the input stream should be repartitioned or not based on whetherparallelism is exhibited (if parallelism, then no need to reparation tomaintain state; but if no parallelism, then need to repartition theinput data to avoid losing state); and (4) when there is no parallelism,create a partitioning transformation for the DAG of executabletransformations for each query stage or each physical CQL query. Thispartitioning transformation is included in the DAG of executabletransformations created by the cluster.

In some embodiments, the analyzing the query plan includes parsing thequery plan and determining each query stage or each physical CQL querythat is included within the query plan. In some embodiments, thedetermining whether parallelism is exhibited for each identified querystage or physical CQL query includes a determination of whether thefunction or transformation can be processed in parallel on multiplenodes without sharing state. For example, a sequential function such asCOUNT could not be processed in parallel on multiple nodes withoutsharing state, and thus a query stage or physical CQL query thatincludes the COUNT function or transformation would be determined toexhibit no parallelism. In some embodiments, determining whether theinput stream should be repartitioned or not includes: (i) determiningthe input stream should not be repartitioned when parallelism isexhibited for the query stage or the physical CQL query, and (ii)determining the input stream should be repartitioned when parallelism isnot exhibited for the query stage or the physical CQL query.

In some embodiments, the creating the partitioning transformation forthe DAG of executable transformations includes determining apartitioning criteria for the query stage or the physical CQL query. Thepartitioning criteria may be an attribute of the syntax. In someembodiments, the partitioning criteria may be the attribute of thesyntax that is acted upon or part of the function or transformation thatcauses the query stage or physical CQL query to not exhibitedparallelism. For example, in the following physical query:

CREATE VIEW tksummarygroupl_v3 AS ISTREAM (SELECT COUNT (ad_id) AStotalads_by_ad_category, ad_category AS ad_category FROMtksummarygroupl_S1 [RANGE 5 seconds] GROUP BY ad_categoryThe group by attribute ad_category is acted upon or part of the functionor transformation that causes the query stage or physical CQL query tonot exhibited parallelism. In other words, in order to process thefunction or transformation without sharing state, the data of the inputstream needs to be partitioned in such a manner that values associatedwith the attribute ad_category are not processed in parallel on multiplenodes without state. Instead, the data of the input stream ispartitioned such that values associated with the attribute ad_categoryare maintained together and the continuous query can be computed on asame node or set of nodes. Once the partition criteria is determined forthe query stage or physical CQL query, a partition transformation 220 iscreated based on the partition criteria and incorporated into the DAG200 of executable transformations 205 created by the cluster, as shownin FIG. 2C. Once the DAG 200 of executable transformations 205 iscreated, a driver node 225 of the cluster can deploy the DAG 200 ofexecutable transformations 205 to worker nodes 230 of the cluster andstart computing transformations 205. As should be understood, thepartition transformation 220 ensures that the data of the input streamis partitioned such that values associated with the partitioningcriteria are maintained together and the transformation 205 is computedon a same node or set of nodes.

This solution is an improvement over prior industry solutions thatutilize GROUP BY statements with aggregate functions. Currently this isnot possible in a single CQL transformation stage. Instead, a user hasto rely on multiple CQL transformation stages which involves joinfunctions. For example, some databases permit two or more differentGROUP BY statements to be used in different sub queries. Each of the subqueries is run as a CQL transformation on its own stage, and thus issimple and a DAG can be created and processed by the cluster for eachCQL transformation on its own stage.

Framework for Logical Queries

In various embodiments, systems, methods, and computer-readable mediaare disclosed for receiving and processing data streaming using a DAG oftransformations on a cluster of distributed nodes. FIG. 3 illustrates aframework 300 for processing data streaming from one or more eventsources in accordance with an exemplary embodiment using EPN 305 (e.g.,EPN 100 as described with respect to FIG. 1). Specifically, EPN 305 maybe configured with various entities that have one or more additionalproperties based on the entities type and purpose. In some embodiments,the entities include a connection 310. Connection 310 is a basicartifact and typically may be created using a catalog (e.g., arepository of entities that can be created by the user). The connection310 may be a collection of metadata (such as URLs, credential and thelike) required to connect to an external system. The connection 310 isthe basis for the creation of sources (Streams, References or GeoFences) and targets. Example of connections may include Kafkaconnections, database connections, and application or software packageconnections such as a GoldenGate connection (a software package forreal-time data integration and replication services).

In some embodiments, the entities further include a source 315. Incertain embodiments, source 315 is a stream or a source of dynamic datawith an input shape. The connection 310 may implemented with the source315 using a creation application (e.g., a wizard) 320, whereby a userselects the connection 310 and specifies the source 315, for example aKafka topic or a URL, that represents the stream of data. In someembodiments, the entities further include a target 325. In certainembodiments, target 325 is an external system or destination where theresults of the stream processing with an output shape are received. Theconnection 310 may implemented with the target 325 using the creationapplication 320, whereby a user selects the connection 310 and specifiesthe target 325, for example input for another pipeline or a URL. Thesome embodiments, the entities further include a pipeline 330 thatdefine pipeline logic and is a sequence of data processing stages.

The pipeline 330 may comprise an event processing application 335 thatis configured to listen to the data stream from source 315, execute acontinuous query using a processor (e.g., a CQL processor) comprisinglogic for processing input data from the data stream. In variousembodiments, the event processing application 235 includes a query planwith a logical CQL query, which may be represented as a directed acyclicgraph (DAG) of physical operators or executable transformations, asdescribed with respect to FIGS. 2A-2D. In some embodiments, a querystage 340 is used to configure the logical CQL query on the data streamfrom the source 315 and may comprise additional sources for joins,filters, subsections such as summaries, group by, and time windows, andso on. The event processing application 335 may further include apattern stage 345, a rule stage 350, and/or a query group 355.

In various embodiments, the query stage 340 includes one or more summarysubsections 360 and one or more group by subsections 365. The summarysubsections 360 may be configured with the creation application 320 withlogical syntax to include one or more aggregate functions (e.g., COUNT,MAX, MIN, SUM, AVG). In certain embodiments, the summary subsections 360are configured with the creation application 320 to include multiplesummaries executed in a single query stage using logical syntax. A DAGmay be created for the logical CQL query and processed by a cluster foreach CQL transformation on its own stage. Once the DAG of executabletransformations is created, a driver node of the cluster can deploy theDAG of executable transformations to worker nodes of the cluster andstart computing transformations.

Methods for Logical Queries

FIG. 4 illustrates processes and operations for implementingfault-tolerant stream processing according to various embodiments.Individual embodiments may be described as a process which is depictedas a flowchart, a flow diagram, a data flow diagram, a structurediagram, or a block diagram. Although a flowchart may describe theoperations as a sequential process, many of the operations may beperformed in parallel or concurrently. In addition, the order of theoperations may be re-arranged. A process is terminated when itsoperations are completed, but could have additional steps not includedin a figure. A process may correspond to a method, a function, aprocedure, a subroutine, a subprogram, etc. When a process correspondsto a function, its termination may correspond to a return of thefunction to the calling function or the main function.

The processes and/or operations depicted in FIG. 4 may be implemented insoftware (e.g., code, instructions, program) executed by one or moreprocessing units (e.g., processors cores), hardware, or combinationsthereof. The software may be stored in a memory (e.g., on a memorydevice, on a non-transitory computer-readable storage medium). Theparticular series of processing steps in FIG. 4 is not intended to belimiting. Other sequences of steps may also be performed according toalternative embodiments. For example, in alternative embodiments thesteps outlined above may be performed in a different order. Moreover,the individual steps illustrated in FIG. 4 may include multiplesub-steps that may be performed in various sequences as appropriate tothe individual step. Furthermore, additional steps may be added orremoved depending on the particular applications. One of ordinary skillin the art would recognize many variations, modifications, andalternatives.

FIG. 4 shows a flowchart 400 that illustrates a process for implementinglogical queries according to various embodiments. In some embodiments,the processes depicted in flowchart 400 may be implemented by the systemof FIG. 1 and framework of FIG. 2. As shown in FIG. 4, at step 405 aquery may be determined as a logical query using a data processingsystem (e.g., the EPN 210 as described with respect to FIG. 2). In someembodiments, the determination is made based on the syntax used todefine the query (e.g., determining whether logical CQL syntax was usedor physical CQL syntax was used). In some embodiments, the logical queryincludes two or more summaries based on different groups configured toexecute in a single query stage of a stream analytics application. Insome embodiments, logical syntax is used to convert a conventional queryplan with physical queries for multiple summaries executed respectivelyin multiple query stages into a query plan with logical queries formultiple summaries executed in a single query stage. In otherembodiments, a creation application is used to create a query plan withlogical queries for multiple summaries executed in a single query stageusing logical syntax. The logical syntax for the logical queries looklike the following: function_identifier ([DISTINCT] arith_expr [BYgroup_by_attrs] [WITHIN window_spec] [WHERE condition]). In someembodiments, determining the query is a logical query further includesdetermining the logical query comprises a first summary (e.g., COUNT)based on a first group (e.g., ad_category) and a second summary (e.g.,SUM) based on a second group (e.g., time_of_day). The first group isdifferent from the second group and the logical query is configured toexecute in a single query stage. For example, the logical query does notcomprise syntax for multiple views and a join of output from thesummaries.

In various embodiments, a DAG of executable transformations isdetermined from the logical query, which can be executed on a cluster ofdistributed nodes. At step 410, the logical query is converted into oneor more physical queries. In some embodiments, upon determining that thequery is expressed as a logical query, the logical query is parsed intomultiple portions, for example, one portion for each function orsummary. The logical syntax/semantics of each portion or summary aretranslated, by the cluster, into physical syntax/semantics for one ormore physical queries such that a physical query is generated for eachportion or summary. In some embodiments, the one or more physicalqueries are separated into individual query stages, and each of thequery stages includes a summary from the two or more summaries that isbased on an associated group. In some embodiments, converting thelogical query to the one or more physical queries includes parsing thelogical query into the first summary (e.g., COUNT) based on a firstgroup (e.g., ad_category) and the second summary (e.g., SUM) based on asecond group (e.g., time_of_day), and translating the logical syntax andsemantics for the first summary (e.g., COUNT) based on a first group(e.g., ad_category) into physical syntax and semantics for a firstphysical query comprising the first summary (e.g., COUNT) based on afirst group (e.g., ad_category) and physical syntax and semantics for asecond physical query comprising the second summary (e.g., SUM) based ona second group (e.g., time_of_day). The first physical query isconfigured to execute in a first query stage of the stream analyticsapplication and the second physical query is configured to execute in asecond query stage of the stream analytics application.

Once the logical query is converted to the one or more physical queries,a DAG of executable transformations may be created comprising atransformation for each query stage corresponding to a summary(aggregate function) view (e.g., each physical query). At step 415, aDAG is generated for the one or more physical queries. In someembodiments, generating the DAG includes creating a physical querytransformation for each of the individual query stages. Each of thesequery stages will receive the same input stream and compute the summaryindividually. In some embodiments, generating the DAG further includescreating a join transformation to join the output from each physicalquery transformation into a single output shape. In some embodiments, aquery plan is created comprising the DAG for the physical query. In someembodiments, the DAG comprises the first query stage as a first physicalquery transformation, the second query stage as a second physical querytransformation, and a join transformation to join the output from eachof the first physical query transformation and the second physical querytransformation into a single output shape.

At optional step 420, the query plan is analyzed to identify each querystage or each physical query within the query plan. In some embodiments,the analyzing the query plan includes parsing the query plan anddetermining each query stage or each physical query that is includedwithin the query plan. At step 425, a determination is made as towhether parallelism is exhibited in each of the one or more physicalqueries. In some embodiments, the determining whether parallelism isexhibited for each identified query stage or physical query includes adetermination of whether the function or transformation can be processedin parallel on multiple nodes without sharing state. For example, asequential function such as COUNT could not be processed in parallel onmultiple nodes without sharing state, and thus a query stage or physicalquery that includes the COUNT function or transformation would bedetermined to exhibit no parallelism. In some embodiments, determiningparallelism includes determining that the first query stage does notexhibit parallelism, determining that the second query stage does notexhibit parallelism, or a combination thereof.

At step 430, when parallelism is not exhibited in a physical query ofthe one or more physical queries, a determination is made as to whetheran input stream is to be partitioned or repartitioned for the physicalquery. In some embodiments, determining whether the input stream shouldbe partitioned or repartitioned, or not, includes: (i) determining theinput stream should not be partitioned or repartitioned when parallelismis exhibited for the query stage or the physical query, and (ii)determining the input stream should be partitioned or repartitioned whenparallelism is not exhibited for the query stage or the physical query.In some embodiments, determining whether an input stream should bepartitioned or repartitioned includes determining that the input streamshould be partitioned or repartitioned for the query plan, determiningthat the input stream should be partitioned or repartitioned for thefirst query stage, determining that the input stream should bepartitioned or repartitioned for the second query stage, or acombination thereof.

At step 435, when the input stream is to be partitioned or repartitionedfor the physical query, creating a partition transformation for thephysical query. Alternatively, when there is parallelism and the inputstream should not be partitioned or repartitioned, a partitioningtransformation is not created for the physical query. In someembodiments, creating the partitioning transformation includes creatingthe partitioning transformation for the query plan, creating thepartitioning transformation for the first query stage, creating thepartitioning transformation for the second query stage, or a combinationthereof. In some embodiments, the partition transformation isincorporated into the directed acyclic graph prior to the physical querytransformation for the physical query.

In some embodiments, the creating the partitioning transformation forthe DAG includes determining a partitioning criteria for the query stageor the physical query. The partitioning criteria may be an attributewithin the physical syntax of the physical query. In some embodiments,the partitioning criteria may be the attribute within the physicalsyntax that is acted upon or part of the function or transformation thatcauses the query stage or physical query to not exhibited parallelism.For example, group by attribute may be acted upon or part of thefunction or transformation that causes the query stage or physical queryto not exhibited parallelism. In other words, in order to process thefunction or transformation without sharing state, the data of the inputstream needs to be partitioned in such a manner that values associatedwith the attribute are not processed in parallel on multiple nodeswithout state. Instead, the data of the input stream is partitioned suchthat values associated with the attribute are maintained together andthe continuous query can be computed on a same node or set of nodes.Once the partition criteria is determined for the query stage orphysical query, a partition transformation is created based on thepartition criteria and incorporated into the DAG created by the cluster.At step 440, the partition transformation is incorporated into the DAGfor the physical query or query plan. Once the DAG is created, a drivernode of the cluster can deploy the DAG to worker nodes of the clusterand start computing transformations on the input stream. As should beunderstood, the partition transformation ensures that the data of theinput stream is partitioned such that values associated with thepartitioning criteria are maintained together and the transformation 205is computed on a same node or set of nodes

Illustrative Systems

FIG. 5 depicts a simplified diagram of a distributed system 500 forimplementing an embodiment. In the illustrated embodiment, distributedsystem 500 includes one or more client computing devices 502, 504, 506,and 508, coupled to a server 512 via one or more communication networks510. Clients computing devices 502, 504, 506, and 508 may be configuredto execute one or more applications.

In various embodiments, server 512 may be adapted to run one or moreservices or software applications that enable receiving and processingdata streaming from an event source.

In certain embodiments, server 512 may also provide other services orsoftware applications that can include non-virtual and virtualenvironments. In some embodiments, these services may be offered asweb-based or cloud services, such as under a Software as a Service(SaaS) model to the users of client computing devices 502, 504, 506,and/or 508. Users operating client computing devices 502, 504, 506,and/or 508 may in turn utilize one or more client applications tointeract with server 512 to utilize the services provided by thesecomponents.

In the configuration depicted in FIG. 5, server 512 may include one ormore components 518, 520 and 522 that implement the functions performedby server 512. These components may include software components that maybe executed by one or more processors, hardware components, orcombinations thereof. It should be appreciated that various differentsystem configurations are possible, which may be different fromdistributed system 500. The embodiment shown in FIG. 5 is thus oneexample of a distributed system for implementing an embodiment systemand is not intended to be limiting.

Users may use client computing devices 502, 504, 506, and/or 508 toreceive and process data streaming from an event source in accordancewith the teachings of this disclosure. A client device may provide aninterface that enables a user of the client device to interact with theclient device. The client device may also output information to the uservia this interface. Although FIG. 5 depicts only four client computingdevices, any number of client computing devices may be supported.

The client devices may include various types of computing systems suchas portable handheld devices, general purpose computers such as personalcomputers and laptops, workstation computers, wearable devices, gamingsystems, thin clients, various messaging devices, sensors or othersensing devices, and the like. These computing devices may run varioustypes and versions of software applications and operating systems (e.g.,Microsoft Windows®, Apple Macintosh®, UNIX® or UNIX-like operatingsystems, Linux or Linux-like operating systems such as Google Chrome™OS) including various mobile operating systems (e.g., Microsoft WindowsMobile®, iOS®, Windows Phone®, Android™, BlackBerry®, Palm OS®).Portable handheld devices may include cellular phones, smartphones,(e.g., an iPhone®), tablets (e.g., iPad®), personal digital assistants(PDAs), and the like. Wearable devices may include Google Glass® headmounted display, and other devices. Gaming systems may include varioushandheld gaming devices, Internet-enabled gaming devices (e.g., aMicrosoft Xbox® gaming console with or without a Kinect® gesture inputdevice, Sony PlayStation® system, various gaming systems provided byNintendo®, and others), and the like. The client devices may be capableof executing various different applications such as variousInternet-related apps, communication applications (e.g., E-mailapplications, short message service (SMS) applications) and may usevarious communication protocols.

Network(s) 510 may be any type of network familiar to those skilled inthe art that can support data communications using any of a variety ofavailable protocols, including without limitation TCP/IP (transmissioncontrol protocol/Internet protocol), SNA (systems network architecture),IPX (Internet packet exchange), AppleTalk®, and the like. Merely by wayof example, network(s) 510 can be a local area network (LAN), networksbased on Ethernet, Token-Ring, a wide-area network (WAN), the Internet,a virtual network, a virtual private network (VPN), an intranet, anextranet, a public switched telephone network (PSTN), an infra-rednetwork, a wireless network (e.g., a network operating under any of theInstitute of Electrical and Electronics (IEEE) 1002.11 suite ofprotocols, Bluetooth®, and/or any other wireless protocol), and/or anycombination of these and/or other networks.

Server 512 may be composed of one or more general purpose computers,specialized server computers (including, by way of example, PC (personalcomputer) servers, UNIX® servers, mid-range servers, mainframecomputers, rack-mounted servers, etc.), server farms, server clusters,or any other appropriate arrangement and/or combination. Server 512 caninclude one or more virtual machines running virtual operating systems,or other computing architectures involving virtualization such as one ormore flexible pools of logical storage devices that can be virtualizedto maintain virtual storage devices for the server. In variousembodiments, server 512 may be adapted to run one or more services orsoftware applications that provide the functionality described in theforegoing disclosure.

The computing systems in server 512 may run one or more operatingsystems including any of those discussed above, as well as anycommercially available server operating system. Server 512 may also runany of a variety of additional server applications and/or mid-tierapplications, including HTTP (hypertext transport protocol) servers, FTP(file transfer protocol) servers, CGI (common gateway interface)servers, JAVA® servers, database servers, and the like. Exemplarydatabase servers include without limitation those commercially availablefrom Oracle®, Microsoft®, Sybase®, IBM® (International BusinessMachines), and the like.

In some implementations, server 512 may include one or more applicationsto analyze and consolidate data feeds and/or event updates received fromusers of client computing devices 502, 504, 506, and 508. As an example,data feeds and/or event updates may include, but are not limited to,Twitter® feeds, Facebook® updates or real-time updates received from oneor more third party information sources and continuous data streams,which may include real-time events related to sensor data applications,financial tickers, network performance measuring tools (e.g., networkmonitoring and traffic management applications), clickstream analysistools, automobile traffic monitoring, and the like. Server 512 may alsoinclude one or more applications to display the data feeds and/orreal-time events via one or more display devices of client computingdevices 502, 504, 506, and 508.

Distributed system 500 may also include one or more data repositories514, 516. These data repositories may be used to store data and otherinformation in certain embodiments. For example, one or more of the datarepositories 514, 516 may be used to store information such as an outputof events. Data repositories 514, 516 may reside in a variety oflocations. For example, a data repository used by server 512 may belocal to server 512 or may be remote from server 512 and incommunication with server 512 via a network-based or dedicatedconnection. Data repositories 514, 516 may be of different types. Incertain embodiments, a data repository used by server 512 may be adatabase, for example, a relational database, such as databases providedby Oracle Corporation® and other vendors. One or more of these databasesmay be adapted to enable storage, update, and retrieval of data to andfrom the database in response to SQL-formatted commands.

In certain embodiments, one or more of data repositories 514, 516 mayalso be used by applications to store application data. The datarepositories used by applications may be of different types such as, forexample, a key-value store repository, an object store repository, or ageneral storage repository supported by a file system.

In certain embodiments, the data stream processing functionalitiesdescribed in this disclosure may be offered as services via a cloudenvironment. FIG. 6 is a simplified block diagram of a cloud-basedsystem environment in which various streaming analytic services may beoffered as cloud services, in accordance with certain embodiments. Inthe embodiment depicted in FIG. 6, cloud infrastructure system 602 mayprovide one or more cloud services that may be requested by users usingone or more client computing devices 604, 606, and 608. Cloudinfrastructure system 602 may comprise one or more computers and/orservers that may include those described above for server 512. Thecomputers in cloud infrastructure system 602 may be organized as generalpurpose computers, specialized server computers, server farms, serverclusters, or any other appropriate arrangement and/or combination.

Network(s) 610 may facilitate communication and exchange of data betweenclients 604, 606, and 608 and cloud infrastructure system 602.Network(s) 610 may include one or more networks. The networks may be ofthe same or different types. Network(s) 610 may support one or morecommunication protocols, including wired and/or wireless protocols, forfacilitating the communications.

The embodiment depicted in FIG. 6 is only one example of a cloudinfrastructure system and is not intended to be limiting. It should beappreciated that, in some other embodiments, cloud infrastructure system602 may have more or fewer components than those depicted in FIG. 6, maycombine two or more components, or may have a different configuration orarrangement of components. For example, although FIG. 6 depicts threeclient computing devices, any number of client computing devices may besupported in alternative embodiments.

The term cloud service is generally used to refer to a service that ismade available to users on demand and via a communication network suchas the Internet by systems (e.g., cloud infrastructure system 602) of aservice provider. Typically, in a public cloud environment, servers andsystems that make up the cloud service provider's system are differentfrom the customer's own on-premise servers and systems. The cloudservice provider's systems are managed by the cloud service provider.Customers can thus avail themselves of cloud services provided by acloud service provider without having to purchase separate licenses,support, or hardware and software resources for the services. Forexample, a cloud service provider's system may host an application, anda user may, via the Internet, on demand, order and use the applicationwithout the user having to buy infrastructure resources for executingthe application. Cloud services are designed to provide easy, scalableaccess to applications, resources and services. Several providers offercloud services. For example, several cloud services are offered byOracle Corporation® of Redwood Shores, Calif., such as middlewareservices, database services, Java cloud services, and others.

In certain embodiments, cloud infrastructure system 602 may provide oneor more cloud services using different models such as under a Softwareas a Service (SaaS) model, a Platform as a Service (PaaS) model, anInfrastructure as a Service (IaaS) model, and others, including hybridservice models. Cloud infrastructure system 602 may include a suite ofapplications, middleware, databases, and other resources that enableprovision of the various cloud services.

A SaaS model enables an application or software to be delivered to acustomer over a communication network like the Internet, as a service,without the customer having to buy the hardware or software for theunderlying application. For example, a SaaS model may be used to providecustomers access to on-demand applications that are hosted by cloudinfrastructure system 602. Examples of SaaS services provided by OracleCorporation® include, without limitation, various services for humanresources/capital management, customer relationship management (CRM),enterprise resource planning (ERP), supply chain management (SCM),enterprise performance management (EPM), analytics services, socialapplications, and others.

An IaaS model is generally used to provide infrastructure resources(e.g., servers, storage, hardware and networking resources) to acustomer as a cloud service to provide elastic compute and storagecapabilities. Various IaaS services are provided by Oracle Corporation®.

A PaaS model is generally used to provide, as a service, platform andenvironment resources that enable customers to develop, run, and manageapplications and services without the customer having to procure, build,or maintain such resources. Examples of PaaS services provided by OracleCorporation® include, without limitation, Oracle Java Cloud Service(JCS), Oracle Database Cloud Service (DBCS), data management cloudservice, various application development solutions services, and others.

Cloud services are generally provided on an on-demand self-servicebasis, subscription-based, elastically scalable, reliable, highlyavailable, and secure manner. For example, a customer, via asubscription order, may order one or more services provided by cloudinfrastructure system 602. Cloud infrastructure system 602 then performsprocessing to provide the services requested in the customer'ssubscription order. For example, receiving and processing data streamingfrom an event source. Cloud infrastructure system 602 may be configuredto provide one or even multiple cloud services.

Cloud infrastructure system 602 may provide the cloud services viadifferent deployment models. In a public cloud model, cloudinfrastructure system 602 may be owned by a third party cloud servicesprovider and the cloud services are offered to any general publiccustomer, where the customer can be an individual or an enterprise. Incertain other embodiments, under a private cloud model, cloudinfrastructure system 602 may be operated within an organization (e.g.,within an enterprise organization) and services provided to customersthat are within the organization. For example, the customers may bevarious departments of an enterprise such as the Human Resourcesdepartment, the Payroll department, etc. or even individuals within theenterprise. In certain other embodiments, under a community cloud model,the cloud infrastructure system 602 and the services provided may beshared by several organizations in a related community. Various othermodels such as hybrids of the above mentioned models may also be used.

Client computing devices 604, 606, and 608 may be of different types(such as devices 502, 504, 506, and 508 depicted in FIG. 5) and may becapable of operating one or more client applications. A user may use aclient device to interact with cloud infrastructure system 602, such asto request a service provided by cloud infrastructure system 602. Forexample, a user may use a client device to request a streaming analyticservice described in this disclosure.

In some embodiments, the processing performed by cloud infrastructuresystem 602 for providing streaming analytic services may involve bigdata analysis. This analysis may involve using, analyzing, andmanipulating large data sets to detect and visualize various trends,behaviors, relationships, etc. within the data. This analysis may beperformed by one or more processors, possibly processing the data inparallel, performing simulations using the data, and the like. Forexample, big data analysis may be performed by cloud infrastructuresystem 602 for processing data streaming from an event source. The dataused for this analysis may include structured data (e.g., data stored ina database or structured according to a structured model) and/orunstructured data (e.g., data blobs (binary large objects)).

As depicted in the embodiment in FIG. 6, cloud infrastructure system 602may include infrastructure resources 630 that are utilized forfacilitating the provision of various cloud services offered by cloudinfrastructure system 602. Infrastructure resources 630 may include, forexample, processing resources, storage or memory resources, networkingresources, and the like.

In certain embodiments, to facilitate efficient provisioning of theseresources for supporting the various cloud services provided by cloudinfrastructure system 602 for different customers, the resources may bebundled into sets of resources or resource modules (also referred to as“pods”). Each resource module or pod may comprise a pre-integrated andoptimized combination of resources of one or more types. In certainembodiments, different pods may be pre-provisioned for different typesof cloud services. For example, a first set of pods may be provisionedfor a database service, a second set of pods, which may include adifferent combination of resources than a pod in the first set of pods,may be provisioned for Java service, and the like. For some services,the resources allocated for provisioning the services may be sharedbetween the services.

Cloud infrastructure system 602 may itself internally use services 632that are shared by different components of cloud infrastructure system602 and which facilitate the provisioning of services by cloudinfrastructure system 602. These internal shared services may include,without limitation, a security and identity service, an integrationservice, an enterprise repository service, an enterprise managerservice, a virus scanning and white list service, a high availability,backup and recovery service, service for enabling cloud support, anemail service, a notification service, a file transfer service, and thelike.

Cloud infrastructure system 602 may comprise multiple subsystems. Thesesubsystems may be implemented in software, or hardware, or combinationsthereof. As depicted in FIG. 6, the subsystems may include a userinterface subsystem 612 that enables users or customers of cloudinfrastructure system 602 to interact with cloud infrastructure system602. User interface subsystem 612 may include various differentinterfaces such as a web interface 614, an online store interface 616where cloud services provided by cloud infrastructure system 602 areadvertised and are purchasable by a consumer, and other interfaces 618.For example, a customer may, using a client device, request (servicerequest 634) one or more services provided by cloud infrastructuresystem 602 using one or more of interfaces 614, 616, and 618. Forexample, a customer may access the online store, browse cloud servicesoffered by cloud infrastructure system 602, and place a subscriptionorder for one or more services offered by cloud infrastructure system602 that the customer wishes to subscribe to. The service request mayinclude information identifying the customer and one or more servicesthat the customer desires to subscribe to. For example, a customer mayplace a subscription order for a streaming analytic related serviceoffered by cloud infrastructure system 602. As part of the order, thecustomer may provide information identifying a source of streaming data.

In certain embodiments, such as the embodiment depicted in FIG. 6, cloudinfrastructure system 602 may comprise an order management subsystem(OMS) 620 that is configured to process the new order. As part of thisprocessing, OMS 620 may be configured to: create an account for thecustomer, if not done already; receive billing and/or accountinginformation from the customer that is to be used for billing thecustomer for providing the requested service to the customer; verify thecustomer information; upon verification, book the order for thecustomer; and orchestrate various workflows to prepare the order forprovisioning.

Once properly validated, OMS 620 may then invoke the order provisioningsubsystem (OPS) 624 that is configured to provision resources for theorder including processing, memory, and networking resources. Theprovisioning may include allocating resources for the order andconfiguring the resources to facilitate the service requested by thecustomer order. The manner in which resources are provisioned for anorder and the type of the provisioned resources may depend upon the typeof cloud service that has been ordered by the customer. For example,according to one workflow, OPS 624 may be configured to determine theparticular cloud service being requested and identify a number of podsthat may have been pre-configured for that particular cloud service. Thenumber of pods that are allocated for an order may depend upon thesize/amount/level/scope of the requested service. For example, thenumber of pods to be allocated may be determined based upon the numberof users to be supported by the service, the duration of time for whichthe service is being requested, and the like. The allocated pods maythen be customized for the particular requesting customer for providingthe requested service.

Cloud infrastructure system 602 may send a response or notification 644to the requesting customer to indicate when the requested service is nowready for use. In some instances, information (e.g., a link) may be sentto the customer that enables the customer to start using and availingthe benefits of the requested services. In certain embodiments, for acustomer requesting the streaming analytic service, the response mayinclude a target for output events.

Cloud infrastructure system 602 may provide services to multiplecustomers. For each customer, cloud infrastructure system 602 isresponsible for managing information related to one or more subscriptionorders received from the customer, maintaining customer data related tothe orders, and providing the requested services to the customer. Cloudinfrastructure system 602 may also collect usage statistics regarding acustomer's use of subscribed services. For example, statistics may becollected for the amount of storage used, the amount of datatransferred, the number of users, and the amount of system up time andsystem down time, and the like. This usage information may be used tobill the customer. Billing may be done, for example, on a monthly cycle.

Cloud infrastructure system 602 may provide services to multiplecustomers in parallel. Cloud infrastructure system 602 may storeinformation for these customers, including possibly proprietaryinformation. In certain embodiments, cloud infrastructure system 602comprises an identity management subsystem (IMS) 628 that is configuredto manage customers information and provide the separation of themanaged information such that information related to one customer is notaccessible by another customer. IMS 628 may be configured to providevarious security-related services such as identity services, such asinformation access management, authentication and authorizationservices, services for managing customer identities and roles andrelated capabilities, and the like.

FIG. 7 illustrates an exemplary computer system 700 that may be used toimplement certain embodiments. For example, in some embodiments,computer system 700 may be used to implement any of the event processingnetwork 100 or 205 as described with respect to FIGS. 1 and 2, andvarious servers and computer systems described above. As shown in FIG.7, computer system 700 includes various subsystems including aprocessing subsystem 704 that communicates with a number of othersubsystems via a bus subsystem 702. These other subsystems may include aprocessing acceleration unit 706, an I/O subsystem 708, a storagesubsystem 718, and a communications subsystem 724. Storage subsystem 718may include non-transitory computer-readable storage media includingstorage media 722 and a system memory 710.

Bus subsystem 702 provides a mechanism for letting the variouscomponents and subsystems of computer system 700 communicate with eachother as intended. Although bus subsystem 702 is shown schematically asa single bus, alternative embodiments of the bus subsystem may utilizemultiple buses. Bus subsystem 702 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, a local bus using any of a variety of bus architectures, and thelike. For example, such architectures may include an Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnect (PCI) bus, which can beimplemented as a Mezzanine bus manufactured to the IEEE P1386.1standard, and the like.

Processing subsystem 704 controls the operation of computer system 700and may comprise one or more processors, application specific integratedcircuits (ASICs), or field programmable gate arrays (FPGAs). Theprocessors may include be single core or multicore processors. Theprocessing resources of computer system 700 can be organized into one ormore processing units 732, 734, etc. A processing unit may include oneor more processors, one or more cores from the same or differentprocessors, a combination of cores and processors, or other combinationsof cores and processors. In some embodiments, processing subsystem 704can include one or more special purpose co-processors such as graphicsprocessors, digital signal processors (DSPs), or the like. In someembodiments, some or all of the processing units of processing subsystem704 can be implemented using customized circuits, such as applicationspecific integrated circuits (ASICs), or field programmable gate arrays(FPGAs).

In some embodiments, the processing units in processing subsystem 704can execute instructions stored in system memory 710 or on computerreadable storage media 722. In various embodiments, the processing unitscan execute a variety of programs or code instructions and can maintainmultiple concurrently executing programs or processes. At any giventime, some or all of the program code to be executed can be resident insystem memory 710 and/or on computer-readable storage media 722including potentially on one or more storage devices. Through suitableprogramming, processing subsystem 704 can provide variousfunctionalities described above. In instances where computer system 700is executing one or more virtual machines, one or more processing unitsmay be allocated to each virtual machine.

In certain embodiments, a processing acceleration unit 706 mayoptionally be provided for performing customized processing or foroff-loading some of the processing performed by processing subsystem 704so as to accelerate the overall processing performed by computer system700.

I/O subsystem 708 may include devices and mechanisms for inputtinginformation to computer system 700 and/or for outputting informationfrom or via computer system 700. In general, use of the term inputdevice is intended to include all possible types of devices andmechanisms for inputting information to computer system 700. Userinterface input devices may include, for example, a keyboard, pointingdevices such as a mouse or trackball, a touchpad or touch screenincorporated into a display, a scroll wheel, a click wheel, a dial, abutton, a switch, a keypad, audio input devices with voice commandrecognition systems, microphones, and other types of input devices. Userinterface input devices may also include motion sensing and/or gesturerecognition devices such as the Microsoft Kinect® motion sensor thatenables users to control and interact with an input device, theMicrosoft Xbox® 360 game controller, devices that provide an interfacefor receiving input using gestures and spoken commands. User interfaceinput devices may also include eye gesture recognition devices such asthe Google Glass® blink detector that detects eye activity (e.g.,“blinking” while taking pictures and/or making a menu selection) fromusers and transforms the eye gestures as inputs to an input device(e.g., Google) Glass®. Additionally, user interface input devices mayinclude voice recognition sensing devices that enable users to interactwith voice recognition systems (e.g., Siri® navigator) through voicecommands.

Other examples of user interface input devices include, withoutlimitation, three dimensional (3D) mice, joysticks or pointing sticks,gamepads and graphic tablets, and audio/visual devices such as speakers,digital cameras, digital camcorders, portable media players, webcams,image scanners, fingerprint scanners, barcode reader 3D scanners, 3Dprinters, laser rangefinders, and eye gaze tracking devices.Additionally, user interface input devices may include, for example,medical imaging input devices such as computed tomography, magneticresonance imaging, position emission tomography, and medicalultrasonography devices. User interface input devices may also include,for example, audio input devices such as MIDI keyboards, digital musicalinstruments and the like.

In general, use of the term output device is intended to include allpossible types of devices and mechanisms for outputting information fromcomputer system 700 to a user or other computer. User interface outputdevices may include a display subsystem, indicator lights, or non-visualdisplays such as audio output devices, etc. The display subsystem may bea cathode ray tube (CRT), a flat-panel device, such as that using aliquid crystal display (LCD) or plasma display, a projection device, atouch screen, and the like. For example, user interface output devicesmay include, without limitation, a variety of display devices thatvisually convey text, graphics and audio/video information such asmonitors, printers, speakers, headphones, automotive navigation systems,plotters, voice output devices, and modems.

Storage subsystem 718 provides a repository or data store for storinginformation and data that is used by computer system 700. Storagesubsystem 718 provides a tangible non-transitory computer-readablestorage medium for storing the basic programming and data constructsthat provide the functionality of some embodiments. Storage subsystem718 may store software (e.g., programs, code modules, instructions) thatwhen executed by processing subsystem 704 provides the functionalitydescribed above. The software may be executed by one or more processingunits of processing subsystem 704. Storage subsystem 718 may alsoprovide a repository for storing data used in accordance with theteachings of this disclosure.

Storage subsystem 718 may include one or more non-transitory memorydevices, including volatile and non-volatile memory devices. As shown inFIG. 7, storage subsystem 718 includes a system memory 710 and acomputer-readable storage media 722. System memory 710 may include anumber of memories including a volatile main random access memory (RAM)for storage of instructions and data during program execution and anon-volatile read only memory (ROM) or flash memory in which fixedinstructions are stored. In some implementations, a basic input/outputsystem (BIOS), containing the basic routines that help to transferinformation between elements within computer system 700, such as duringstart-up, may typically be stored in the ROM. The RAM typically containsdata and/or program modules that are presently being operated andexecuted by processing subsystem 704. In some implementations, systemmemory 710 may include multiple different types of memory, such asstatic random access memory (SRAM), dynamic random access memory (DRAM),and the like.

By way of example, and not limitation, as depicted in FIG. 7, systemmemory 710 may load application programs 712 that are being executed,which may include various applications such as Web browsers, mid-tierapplications, relational database management systems (RDBMS), etc.,program data 714, and an operating system 716. By way of example,operating system 716 may include various versions of Microsoft Windows®,Apple Macintosh®, and/or Linux operating systems, a variety ofcommercially-available UNIX® or UNIX-like operating systems (includingwithout limitation the variety of GNU/Linux operating systems, theGoogle Chrome® OS, and the like) and/or mobile operating systems such asiOS, Windows® Phone, Android® OS, BlackBerry® OS, Palm® OS operatingsystems, and others.

Computer-readable storage media 722 may store programming and dataconstructs that provide the functionality of some embodiments.Computer-readable media 722 may provide storage of computer-readableinstructions, data structures, program modules, and other data forcomputer system 700. Software (programs, code modules, instructions)that, when executed by processing subsystem 704 provides thefunctionality described above, may be stored in storage subsystem 718.By way of example, computer-readable storage media 722 may includenon-volatile memory such as a hard disk drive, a magnetic disk drive, anoptical disk drive such as a CD ROM, DVD, a Blu-Ray® disk, or otheroptical media. Computer-readable storage media 722 may include, but isnot limited to, Zip® drives, flash memory cards, universal serial bus(USB) flash drives, secure digital (SD) cards, DVD disks, digital videotape, and the like. Computer-readable storage media 722 may alsoinclude, solid-state drives (SSD) based on non-volatile memory such asflash-memory based SSDs, enterprise flash drives, solid state ROM, andthe like, SSDs based on volatile memory such as solid state RAM, dynamicRAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, andhybrid SSDs that use a combination of DRAM and flash memory based SSDs.

In certain embodiments, storage subsystem 718 may also include acomputer-readable storage media reader 720 that can further be connectedto computer-readable storage media 722. Reader 720 may receive and beconfigured to read data from a memory device such as a disk, a flashdrive, etc.

In certain embodiments, computer system 700 may support virtualizationtechnologies, including but not limited to virtualization of processingand memory resources. For example, computer system 700 may providesupport for executing one or more virtual machines. In certainembodiments, computer system 700 may execute a program such as ahypervisor that facilitated the configuring and managing of the virtualmachines. Each virtual machine may be allocated memory, compute (e.g.,processors, cores), I/O, and networking resources. Each virtual machinegenerally runs independently of the other virtual machines. A virtualmachine typically runs its own operating system, which may be the sameas or different from the operating systems executed by other virtualmachines executed by computer system 700. Accordingly, multipleoperating systems may potentially be run concurrently by computer system700.

Communications subsystem 724 provides an interface to other computersystems and networks. Communications subsystem 724 serves as aninterface for receiving data from and transmitting data to other systemsfrom computer system 700. For example, communications subsystem 724 mayenable computer system 700 to establish a communication channel to oneor more client devices via the Internet for receiving and sendinginformation from and to the client devices. For example, thecommunication subsystem may be used to establish a connection with asource of streaming data.

Communication subsystem 724 may support both wired and/or wirelesscommunication protocols. For example, in certain embodiments,communications subsystem 724 may include radio frequency (RF)transceiver components for accessing wireless voice and/or data networks(e.g., using cellular telephone technology, advanced data networktechnology, such as 3G, 4G or EDGE (enhanced data rates for globalevolution), WiFi (IEEE 802.XX family standards, or other mobilecommunication technologies, or any combination thereof), globalpositioning system (GPS) receiver components, and/or other components.In some embodiments communications subsystem 724 can provide wirednetwork connectivity (e.g., Ethernet) in addition to or instead of awireless interface.

Communication subsystem 724 can receive and transmit data in variousforms. For example, in some embodiments, in addition to other forms,communications subsystem 724 may receive input communications in theform of structured and/or unstructured data feeds 726, event streams728, event updates 730, and the like. For example, communicationssubsystem 724 may be configured to receive (or send) data feeds 726 inreal-time from users of social media networks and/or other communicationservices such as Twitter® feeds, Facebook® updates, web feeds such asRich Site Summary (RSS) feeds, and/or real-time updates from one or morethird party information sources.

In certain embodiments, communications subsystem 724 may be configuredto receive data in the form of continuous data streams, which mayinclude event streams 728 of real-time events and/or event updates 730,that may be continuous or unbounded in nature with no explicit end.Examples of applications that generate continuous data may include, forexample, sensor data applications, financial tickers, networkperformance measuring tools (e.g. network monitoring and trafficmanagement applications), clickstream analysis tools, automobile trafficmonitoring, and the like.

Communications subsystem 724 may also be configured to communicate datafrom computer system 700 to other computer systems or networks. The datamay be communicated in various different forms such as structured and/orunstructured data feeds 726, event streams 728, event updates 730, andthe like to one or more databases that may be in communication with oneor more streaming data source computers coupled to computer system 700.

Computer system 700 can be one of various types, including a handheldportable device (e.g., an iPhone® cellular phone, an iPad® computingtablet, a PDA), a wearable device (e.g., a Google Glass® head mounteddisplay), a personal computer, a workstation, a mainframe, a kiosk, aserver rack, or any other data processing system. Due to theever-changing nature of computers and networks, the description ofcomputer system 700 depicted in FIG. 7 is intended only as a specificexample. Many other configurations having more or fewer components thanthe system depicted in FIG. 7 are possible. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the variousembodiments.

Although specific embodiments have been described, variousmodifications, alterations, alternative constructions, and equivalentsare possible. Embodiments are not restricted to operation within certainspecific data processing environments, but are free to operate within aplurality of data processing environments. Additionally, althoughcertain embodiments have been described using a particular series oftransactions and steps, it should be apparent to those skilled in theart that this is not intended to be limiting. Although some flowchartsdescribe operations as a sequential process, many of the operations canbe performed in parallel or concurrently. In addition, the order of theoperations may be rearranged. A process may have additional steps notincluded in the figure. Various features and aspects of theabove-described embodiments may be used individually or jointly.

Further, while certain embodiments have been described using aparticular combination of hardware and software, it should be recognizedthat other combinations of hardware and software are also possible.Certain embodiments may be implemented only in hardware, or only insoftware, or using combinations thereof. The various processes describedherein can be implemented on the same processor or different processorsin any combination.

Where devices, systems, components or modules are described as beingconfigured to perform certain operations or functions, suchconfiguration can be accomplished, for example, by designing electroniccircuits to perform the operation, by programming programmableelectronic circuits (such as microprocessors) to perform the operationsuch as by executing computer instructions or code, or processors orcores programmed to execute code or instructions stored on anon-transitory memory medium, or any combination thereof. Processes cancommunicate using a variety of techniques including but not limited toconventional techniques for inter-process communications, and differentpairs of processes may use different techniques, or the same pair ofprocesses may use different techniques at different times.

Specific details are given in this disclosure to provide a thoroughunderstanding of the embodiments. However, embodiments may be practicedwithout these specific details. For example, well-known circuits,processes, algorithms, structures, and techniques have been shownwithout unnecessary detail in order to avoid obscuring the embodiments.This description provides example embodiments only, and is not intendedto limit the scope, applicability, or configuration of otherembodiments. Rather, the preceding description of the embodiments willprovide those skilled in the art with an enabling description forimplementing various embodiments. Various changes may be made in thefunction and arrangement of elements.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that additions, subtractions, deletions, and other modificationsand changes may be made thereunto without departing from the broaderspirit and scope as set forth in the claims. Thus, although specificembodiments have been described, these are not intended to be limiting.Various modifications and equivalents are within the scope of thefollowing claims.

What is claimed is:
 1. A method, comprising: determining, by a dataprocessing system, a query is a logical query, wherein the logical queryincludes two or more summaries based on different group by statementsconfigured to execute in a single query stage of a stream analyticsapplication, wherein the determining the query is the logical queryincludes determining the logical query comprises a first summary of thetwo or more summaries based on a first group by statement of thedifferent group by statements and a second summary of the two or moresummaries based on a second group by statement of the different group bystatements, and wherein the first group by statement is different fromthe second group by statement; converting, by the data processingsystem, the logical query into one or more physical queries, wherein theone or more physical queries are separated into individual query stages,and each of the query stages includes a summary from the two or moresummaries that is based on an associated group by statement, wherein theconverting the logical query into the one or more physical queriesincludes parsing the logical query into the first summary based on thefirst group by statement and the second summary based on the secondgroup by statement, translating logical syntax and semantics for thefirst summary into physical syntax and semantics for a first physicalquery comprising the first summary based on the first group bystatement, and translating logical syntax and semantics for the secondsummary into physical syntax and semantics for a second physical querycomprising the second summary based on the second group by statement;and generating, by the data processing system, a directed acyclic graphfor the one or more physical queries, wherein the directed acyclic graphincludes a physical query transformation for each of the individualquery stages.
 2. The method of claim 1, wherein the first physical queryis configured to execute in a first query stage and the second physicalquery is configured to execute in a second query stage.
 3. The method ofclaim 2, wherein the directed acyclic graph comprises the first querystage as a first physical query transformation, the second query stageas a second physical query transformation, and a join transformation tojoin output from each of the first physical query transformation and thesecond physical query transformation into a single output shape.
 4. Amethod, comprising: determining, by a data processing system, a query isa logical query, wherein the logical query includes two or moresummaries based on different group by statements configured to executein a single query stage of a stream analytics application; converting,by the data processing system, the logical query into one or morephysical queries, wherein the one or more physical queries are separatedinto individual query stages, and each of the query stages includes asummary from the two or more summaries that is based on an associatedgroup by statement; generating, by the data processing system, adirected acyclic graph for the one or more physical queries, wherein thedirected acyclic graph includes a physical query transformation for eachof the individual query stages; determining, by the data processingsystem, whether parallelism is exhibited in each of the one or morephysical queries; when parallelism is not exhibited in a physical queryof the one or more physical queries, determining, by the data processingsystem, an input stream is to be partitioned or repartitioned for thephysical query; and when the input stream is to be partitioned orrepartitioned for the physical query, creating, by the data processingsystem, a partition transformation for the physical query, wherein thepartition transformation is incorporated into the directed acyclic graphprior to the physical query transformation for the physical query, andwherein the creating the partition transformation includes determining apartitioning criteria for the physical query, wherein the partitioningcriteria is an attribute within physical syntax of the physical querythat is acted upon or part of a function or transformation that causesthe physical query to not exhibited parallelism.
 5. A system comprising:a data processing system that includes one or more processors andnon-transitory machine readable storage medium having instructionsstored thereon that when executed by the one or more processors causethe one or more processors to perform the process comprising:determining, by the data processing system, a query is a logical query,wherein the logical query includes two or more summaries based ondifferent group by statements configured to execute in a single querystage of a stream analytics application, wherein the determining thequery is the logical query includes determining the logical querycomprises a first summary of the two or more summaries based on a firstgroup by statement of the different group by statements and a secondsummary of the two or more summaries based on a second group bystatement of the different group by statements, and wherein the firstgroup by statement is different from the second group by statement;converting, by the data processing system, the logical query into one ormore physical queries, wherein the one or more physical queries areseparated into individual query stages, and each of the query stagesincludes a summary from the two or more summaries that is based on anassociated group by statement, wherein the converting the logical queryinto the one or more physical queries includes parsing the logical queryinto the first summary based on the first group by statement and thesecond summary based on the second group by statement, translatinglogical syntax and semantics for the first summary into physical syntaxand semantics for a first physical query comprising the first summarybased on the first group by statement, and translating logical syntaxand semantics for the second summary into physical syntax and semanticsfor a second physical query comprising the second summary based on thesecond group by statement; and generating, by the data processingsystem, a directed acyclic graph for the one or more physical queries,wherein the directed acyclic graph includes a physical querytransformation for each of the individual query stages.
 6. The system ofclaim 5, wherein the first physical query is configured to execute in afirst query stage and the second physical query is configured to executein a second query stage.
 7. The system of claim 6, wherein the directedacyclic graph comprises the first query stage as a first physical querytransformation, the second query stage as a second physical querytransformation, and a join transformation to join output from each ofthe first physical query transformation and the second physical querytransformation into a single output shape.
 8. A system comprising: adata processing system that includes one or more processors andnon-transitory machine readable storage medium having instructionsstored thereon that when executed by the one or more processors causethe one or more processors to perform the process comprising:determining, by the data processing system, a query is a logical query,wherein the logical query includes two or more summaries based ondifferent group by statements configured to execute in a single querystage of a stream analytics application; converting, by the dataprocessing system, the logical query into one or more physical queries,wherein the one or more physical queries are separated into individualquery stages, and each of the query stages includes a summary from thetwo or more summaries that is based on an associated group by statement;generating, by the data processing system, a directed acyclic graph forthe one or more physical queries, wherein the directed acyclic graphincludes a physical query transformation for each of the individualquery stages; determining, by the data processing system, whetherparallelism is exhibited in each of the one or more physical queries;when parallelism is not exhibited in a physical query of the one or morephysical queries, determining, by the data processing system, an inputstream is to be partitioned or repartitioned for the physical query; andwhen the input stream is to be partitioned or repartitioned for thephysical query, creating, by the data processing system, a partitiontransformation for the physical query, wherein the partitiontransformation is incorporated into the directed acyclic graph prior tothe physical query transformation for the physical query, and whereinthe creating the partition transformation includes determining apartitioning criteria for the physical query, wherein the partitioningcriteria is an attribute within physical syntax of the physical querythat is acted upon or part of a function or transformation that causesthe physical query to not exhibited parallelism.
 9. A non-transitorymachine readable storage medium having instructions stored thereon thatwhen executed by one or more processors cause the one or more processorsto perform a method comprising: determining a query is a logical query,wherein the logical query includes two or more summaries based ondifferent group by statements configured to execute in a single querystage of a stream analytics application, wherein the determining thequery is the logical query includes determining the logical querycomprises a first summary of the two or more summaries based on a firstgroup by statement of the different group by statements and a secondsummary of the two or more summaries based on a second group bystatement of the different group by statements, and wherein the firstgroup by statement is different from the second group by statement;converting the logical query into one or more physical queries, whereinthe one or more physical queries are separated into individual querystages, and each of the query stages includes a summary from the two ormore summaries that is based on an associated group by statement,wherein the converting the logical query into the one or more physicalqueries includes parsing the logical query into the first summary basedon the first group by statement and the second summary based on thesecond group by statement, translating logical syntax and semantics forthe first summary into physical syntax and semantics for a firstphysical query comprising the first summary based on the first group bystatement, and translating logical syntax and semantics for the secondsummary into physical syntax and semantics for a second physical querycomprising the second summary based on the second group by statement;and generating a directed acyclic graph for the one or more physicalqueries, wherein the directed acyclic graph includes a physical querytransformation for each of the individual query stages.
 10. Thenon-transitory machine readable storage medium of claim 9, wherein thefirst physical query is configured to execute in a first query stage andthe second physical query is configured to execute in a second querystage.
 11. The non-transitory machine readable storage medium of claim10, wherein the directed acyclic graph comprises the first query stageas a first physical query transformation, the second query stage as asecond physical query transformation, and a join transformation to joinoutput from each of the first physical query transformation and thesecond physical query transformation into a single output shape.
 12. Anon-transitory machine readable storage medium having instructionsstored thereon that when executed by one or more processors cause theone or more processors to perform a method comprising: determining aquery is a logical query, wherein the logical query includes two or moresummaries based on different group by statements configured to executein a single query stage of a stream analytics application; convertingthe logical query into one or more physical queries, wherein the one ormore physical queries are separated into individual query stages, andeach of the query stages includes a summary from the two or moresummaries that is based on an associated group by statement; generatinga directed acyclic graph for the one or more physical queries, whereinthe directed acyclic graph includes a physical query transformation foreach of the individual query stages; determining whether parallelism isexhibited in each of the one or more physical queries; when parallelismis not exhibited in a physical query of the one or more physicalqueries, determining an input stream is to be partitioned orrepartitioned for the physical query; and when the input stream is to bepartitioned or repartitioned for the physical query, creating apartition transformation for the physical query, wherein the partitiontransformation is incorporated into the directed acyclic graph prior tothe physical query transformation for the physical query, and whereinthe creating the partition transformation includes determining apartitioning criteria for the physical query, wherein the partitioningcriteria is an attribute within physical syntax of the physical querythat is acted upon or part of a function or transformation that causesthe physical query to not exhibited parallelism.